lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Engels" <>
Subject RE: optimized reopen?
Date Thu, 12 May 2005 01:10:25 GMT
I did an implementation of IndexReader.reopen() in my modified Lucene lib.

It is over 200% faster than closing and opening the index.

I just made the semantics of IndexReader.reopen() be that the original
IndexReader is now closed, and can no longer be used (since I cannot close()
the original, otherwise the SegmentReaders will close, so I close the unused
SegmentReaders directly). In order to make this work I also needed to make
commit() public, since the commit() needs to be performed prior to the
segment merging, and I needed to add a package method to MultiReader to get
the underlying subReaders.

Although this may not be useful to many, in our case since we use a single
shared reader and a single exclusive writer in a server process (with
external locking, so we can guarantee than when the IndexReader is "rolled",
there are no references to the previous reader.


-----Original Message-----
From: Yonik Seeley []
Sent: Wednesday, May 11, 2005 4:50 PM
Subject: Re: optimized reopen?

Things are cached using an IndexReader as the key, so you would have
to be careful not to break the current behaviour (that an
IndexReader's view of an index doesn't change - deletes from that
specific reader aside).

Maybe you could invoke reopen() on an existing IndexReader and it
would return a new IndexReader that shares sub-readers that haven't
changed?  But I don't think that sub-readers can be shared like this
right now... the difficulty may lie in deleted-docs.


On 5/11/05, Robert Engels <> wrote:
> Is there any way to optimize the closing & reopening of an Index?
> Since the opens a MultiReader is there are multiple
> segments, it seems a reopen() method could be implemented, which detects
> which segments are the same as the current open index, and then passes
> SegementReaders to a new Multireader rather than creating new
> for the unmodified segments.
> Does this sounds feasible? Would it improve the performance?
> Thanks

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

View raw message