lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doron Cohen <>
Subject Re: Concurrent merge
Date Wed, 21 Feb 2007 23:07:39 GMT
Ning Li wrote:

> There are three main challenges in enabling concurrent merge:
>   1 a robust merge policy
>   2 detect when merge lags document additions/deletions
>   3 how to slow down document additions/deletions (and amortize
>     the cost) when merge falls behind

I wonder what it means for current API semantics -

- An application today can set max-bufferred-docs to N, and after
the Nth (or N+1th?) call to addDoc returns, a newly opened searcher
would see these docs. With merges in a background thread this
might not hold.

- Today, after add(), an application can call flush() or close(),
but with a background merge thread these calls would be blocked.
Mmm... this is probably not a behavior change, because today
these operations can trigger a merge that would take a long(er) time.

- numRamDocs() and ramSizeInBytes() - not sure what they mean
once a background merge thread had started.

Still, having non blocking adds is compelling.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message