Sure, but remember: 1) this is the exception case (not the rule)
I disagree ... I find myself more and more these days telling people to limit their merge size because of performance issues, whether it's for optimize/maybeMerge. Therefore I don't think it's the exception case, or will remain like that for long.
But today, in 3.x or trunk (ie TieredMergePolicy), if you call
forceMerge(N) this will in fact merge away until you have <= N
I think if you use either LogDoc/ByteSizeMergePolicy, forceMerge also
does what it says. It's only if you change their maxMBForOptimize from
the default, and you have a large enough index to hit that limit, that
forceMerge(1) may in fact produce more than one segment.
So, sure, if you go and change the settings, swap in a different
MergePolicy, etc., you can make it so IW.forceMerge(int) does
something totally different. But that's the exception, not the rule;
that's what the "experts" do, not the normal users who use the
I think forceMerge(int) does a pretty good job explaining what the MP is going to try to do.
Is that a Javadoc statement? Because we could have just fixed optimize() javadocs without adding API that sort of commits to something that may not happen.
I think in the javadocs we should explain that forceMerge just asks
the MP to pick merges, passing the minSegmentCount, ie explain the
"exception case" via javadocs and let the method name explain the
common case. I think this is in general how we should name our
How about naming it doMaintenance?
I don't really like that choice, for the same reason I don't like
defragment/compact: it implies you (the app) are expected to
periodically call it, whereas forced merging is very much an optional
operation since Lucene works so well against multi-segment indexes
If we took this approach... I think IW would still need a "default MP" that it uses to kick off natural merges over time? (Ie, after a new segment is flushed).
Sure, we will provide the best MP for doing natural/regular merges which will be the default of IWC.
I agree this route is bigger than just renaming optimize(), and I don't think that we need to change the interaction between IW and MP. But let's handle that in a separate issue.
Can you open a new issue so we can explore the foreign-MP idea?
Replacing optimize/forceMerge and expungeDeletes with a new
"merge(MP)" seems compelling.
Let's leave this issue on the simple renaming....