On Fri, Apr 3, 2009 at 8:01 PM, Jason Rutherglen
<jason.rutherg...@gmail.com> wrote:
> I looked at the IndexWriter code in regards to creating a realtime reader,
> with the many flexible indexing classes I'm unsure of how one would get a
> frozenish IndexInput of the byte slices, given the byte slices are attached
> to different threads?
The realtime reader would have to have sub-readers per thread, and an
aggregate reader that "joins" them by interleaving the docIDs. When
flushing we create such a beast, but, it's not general purpose (ie it
does not implement IndexReader API; it only implements enough to write
the postings).
BTW there are benefits to not reusing the RAM buffer, outside of
faster near real-time search: it would allow flushing to be done in
the BG. Ie, flush could start, and we'd immediately switch to a new
RAM buffer, thus allowing add/deletes in other threads to run.
Currently they are all blocked ("stop the world") during flush, though
it's not clear on a fast IO device (SSD) how big a deal this "stop the
world" really is to indexing throughput.
But still it's a complex change.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
