[
https://issues.apache.org/jira/browse/LUCENE-3454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146664#comment-13146664
]
Michael McCandless commented on LUCENE-3454:
--------------------------------------------
{quote}
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.
{quote}
But today, in 3.x or trunk (ie TieredMergePolicy), if you call
forceMerge(N) this will in fact merge away until you have <= N
segments.
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
defaults.
{quote}
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.
{quote}
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
methods...
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.
{quote}
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.
{quote}
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: https://issues.apache.org/jira/browse/LUCENE-3454
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
