Since Lucene 2.9, Lucene works on a per segment basis when searching. Since Lucene 3.1 it can even parallelize on multiple segments. If you optimize your index you only have one segment. Also, when you frequently reopen your indexes (e.g. after updates), the cost for warming the cache and FieldCache for a very large new segment ( and the CPU power lost for optimizing the whole index) does not rectify a more compact representation on disk. For search performance it has a minor impact.
It's a much better idea to configure the MergePolicy accordingly to merge segments optimally (Lucene 3.2 has a TieredMergePolicy that's now the default). This one will minimize number of segments. The same overhead applies to Solr when you replicate your index. If you don't optimize, Solr will only exchange new segments between the indexes. As after a optimize the whole index is rebuilt, it has to always transfer the whole index files to the replicas. Optimizing only makes sense for e.g. read-only indexes that are build one time and never touched. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Yury Kats [mailto:[email protected]] > Sent: Tuesday, June 14, 2011 3:04 PM > To: [email protected] > Subject: Re: Indexing slower in trunk > > On 6/14/2011 4:28 AM, Uwe Schindler wrote: > > indexing and optimizing was only a > > good idea pre Lucene-2.9, now it's mostly obsolete) > > Could you please elaborate on this? Is optimizing obsolete in general or after > indexing new documents? Is it obsolete after deletions? And what it > "mostly"? > > Thanks! > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
