On Mon, Sep 8, 2008 at 12:33 PM, Michael McCandless <[EMAIL PROTECTED]> wrote: > I'd also trying to make time to explore the approach of creating an > IndexReader impl. that searches IndexWriter's RAM buffer.
That seems like it could possibly be the best performing approach in the long run. > I think it's quite feasible, but, it'd still have a "reopen" cost in that > any buffered delete by term or query would have to be "materialiazed" into > docIDs on reopen. Though, if this somehow turns out to be a problem, in the > future we could do this materializing immediately, instead of buffering, if > we already have a reader open. Right... it seems like re-using readers internally is something we could already be doing in IndexWriter. > Flushing is somewhat tricky because any open RAM readers would then have to > cutover to the newly flushed segment once the flush completes, so that the > RAM buffer can be recycled for the next segment. Re-use of a RAM buffer doesn't seem like such a big deal. But, how would you maintain a static view of an index...? IndexReader r1 = indexWriter.getCurrentIndex() indexWriter.addDocument(...) IndexReader r2 = indexWriter.getCurrentIndex() I assume r1 will have a view of the index before the document was added, and r2 after? Another thing that will help is if users could get their hands on the sub-readers of a multi-segment reader. Right now that is hidden in MultiSegmentReader and makes updating anything incrementally difficult. -Yonik --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
