On Tue, Sep 22, 2009 at 11:37 AM, Michael McCandless <luc...@mikemccandless.com> wrote: > The whole point of putting optional warming into IndexWriter was so > the segment could be warmed *before* the merge commits the change to > the writer's SegmentInfos.
But... doesn't this add the same amount of latency in a different place (moves it from after the commit to before the commit)? Seems like the total latency from when the doc is added to when it's searchable is the same in both cases? > Any newly opened near-real-timer readers > continue to search the old (merged away) segments, until the warming > completes. If the application is doing warming, it can use the same approach... don't immediately expose the result of IW.getReader - warm it first and have requests go against the old one in the meantime. I like IW.getReader()... it adds functionality that one couldn't do at the application layer. I'm still missing what adding warming does that can't easily be done at the application layer. It can also result in warming of segments that will never be used (because they will be merged again before getReader() is called. -Yonik http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
