lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3454) rename optimize to a less cool-sounding name
Date Tue, 08 Nov 2011 23:51:51 GMT


Michael McCandless commented on LUCENE-3454:

bq. 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

bq. 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

bq. 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
these days.

bq. 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....

> rename optimize to a less cool-sounding name
> --------------------------------------------
>                 Key: LUCENE-3454
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 3.4, 4.0
>            Reporter: Robert Muir
>            Assignee: Michael McCandless
>         Attachments: LUCENE-3454.patch
> I think users see the name optimize and feel they must do this, because who wants a suboptimal
system? but this probably just results in wasted time and resources.
> maybe rename to collapseSegments or something?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message