On 2/21/07, Ning Li <[EMAIL PROTECTED]> wrote:
I agree that the current blocking model works for some applications,
especially if the indexes are batch built.
But other applications, e.g. with online indexes, would greatly
benefit from a non-blocking model. Most systems that merge data
support background merges. As long as we keep it simple (how about the
original proposal?), applications will benefit from this.
Yes, if we do anything, I think simple is better. I wouldn't go down
the whole soft-limit/hard-limit, gradually slowing down additions
road... the complexity doesn't sound worth it.
The simplest model could just take a reference to the ram segments and
the deleted terms on a flush, and then another thread could then do
merging into a single segment, term deletion, and any other necessary
merging, while the original thread created new empty ram-segments and
deleted-terms so additions could continue. If the user added more
than maxBufferedDocs before the background merge was complete, the add
would block (as it does currently).
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
