lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Optimize taking two steps and extra disk space
Date Sun, 19 Jun 2011 16:35:19 GMT
On 6/19/2011 7:32 AM, Michael McCandless wrote:
> With LogXMergePolicy (the default before 3.2), optimize respects
> mergeFactor, so it's doing 2 steps because you have 37 segments but 35
> mergeFactor.
> With TieredMergePolicy (default on 3.2 and after), there is now a
> separate merge factor used for optimize (maxMergeAtOnceExplicit)... so
> you could eg set this factor higher and more often get a single merge
> for the optimize.

This makes sense.  the default for maxMergeAtOnceExplicit is 30 
according to LUCENE-854, so it merges the first 30 segments, then it 
goes back and merges the new one plus the other 7 that remain.  To 
counteract this behavior, I've put this in my solrconfig.xml, to test 
next week.

<mergePolicy class="org.apache.lucene.index.TieredMergePolicy">
<int name="maxMergeAtOnceExplicit">70</int>

I figure that twice the megeFactor (35) will likely cover every possible 
outcome.  Is that a correct thought?


View raw message