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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
