It's likely the RAMDir approach will still be a performance win over getReader, until LUCENE-1313 is in (which uses a RAMDir for the small-enough newly flushed segments). getReader() writes (but doesn't sync) the new segment files to the Directory, and then opens a new SegmentReader on those files, so it's paying the IO cost that the RAMDir approach doesn't. I'd love to see some real world results on this, though; I think likely the gains are minor.
The biggest win for NRT was switching to per-segment Collector because that meant we could re-use FieldCache entries for all segments that hadn't changed. Mike On Sat, Aug 1, 2009 at 7:52 AM, Grant Ingersoll<gsing...@apache.org> wrote: > In many NRT cases, it seems the traditional approach has been to have two > RAM directories and a write-through FS Directory (for example Zoie does > this, and it has also been discussed a fair number of times on the various > lists). I'm wondering how the new IndexWriter.getReader stuff relates to > that approach? Is there even a need for the RAM dirs at this point? > > -Grant > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
