As the wiki does say: "if at all ... Segments are normally merged over time
anyway (as determined by the merge policy), and optimize just forces these
merges to occur immediately."
So, the only real question here is if the optimize really does lie outside
the "if at all" category and whether "Segments are normally merged over time
anyway" is in fact not good enough.
This is why I referred to "the intent" - whether the actual reality of a
specific Solr application does align with the expectation that "Segments are
normally merged over time anyway". But, start with the presumption that
merge policy does eliminate the need for optimize.
As a general proposition:
1. Try to avoid using optimize "if at all" possible. Let merge policy do its
thing.
2. Try to take a server out offline while optimizing if an optimize is
really absolutely needed.
3. Try to understand why #1 is not sufficient and resolve the cause(s), so
that optimize is no longer needed.
-- Jack Krupansky
-----Original Message-----
From: Yonik Seeley
Sent: Monday, May 27, 2013 9:46 AM
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
