lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <>
Subject Re: Realtime Search for Social Networks Collaboration
Date Mon, 08 Sep 2008 18:43:18 GMT
On Mon, Sep 8, 2008 at 12:33 PM, Michael McCandless
<> 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()
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


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

View raw message