Per segment over many segments is actually a bit faster for none sort
cases and many sort cases -but an optimized index will still be
fastest - the speed benifit of many segments comes when reopening - so
say for realtime search - in that case you may want to sac the opt
perf for a segment tail that is faster on update turnaround time. But
for straight search speed - optimized is still the the way to go.
- Mark
http://www.lucidimagination.com (mobile)
On Oct 1, 2009, at 4:47 AM, Marc Sturlese <marc.sturl...@gmail.com>
wrote:
Hey there,
Until now when using Lucene 2.4 I was always optimizing my index using
compound file after updating it. I was doing that because if not I
could
feel a lot performance loss in search responses.
Now in Lucene 2.9 there are per segment readers and I have read
something
about it performes better and maybe there's no need to optimze
always the
index.
For FieldCache usage I know in Lucene 2.9 due to the per segment
readers the
seed at loading time as imporved a lot if the index is not
optimized. But if
it is optimized the loading time is the same.
So, is that true that with per segment reders search request perform
almost
as good as an optimized index? Can anyone point me where to get more
information about the Lucene 2.9 per segments reader?
Thanks in advance
--
View this message in context:
http://www.nabble.com/Lucene-2.9-and-performance-of-readers-per-segment.-tp25695093p25695093.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
