forceMerge is very useful if you delete a significant portion of an index. It can take a very long time before any merge policy decides to finally merge them all away, especially for a static or infrequently changing index. Also, having a lot of deleted docs in the index can be an issue if your similarity uses maxDoc for IDF.
The cost is also much lower when using SSD's, forceMerging a 1GB core is a matter of seconds. -----Original message----- > From:Yonik Seeley <yo...@lucidworks.com> > Sent: Mon 27-May-2013 15:47 > To: solr-user@lucene.apache.org > Subject: Re: Overlapping onDeckSearchers=2 > > On Mon, May 27, 2013 at 7:11 AM, Jack Krupansky <j...@basetechnology.com> > wrote: > > The intent is that optimize is obsolete and should no longer be used > > That's incorrect. > > People need to understand the cost of optimize, and that it's use is optional. > It's up to the developer to figure out of the benefits of calling > optimize outweigh the costs in their particular situations. > > The wiki currently says: > """ > An optimize is like a hard commit except that it forces all of the > index segments to be merged into a single segment first. Depending on > the use cases, this operation should be performed infrequently (like > nightly), if at all, since it is very expensive and involves reading > and re-writing the entire index. Segments are normally merged over > time anyway (as determined by the merge policy), and optimize just > forces these merges to occur immediately. > """ > > -Yonik > http://lucidworks.com >
