lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3569) Consolidate IndexWriter's optimize, maybeMerge and expungeDeletes under one merge(MP) method
Date Tue, 15 Nov 2011 04:47:51 GMT


Shai Erera commented on LUCENE-3569:

bq. "Maintenance" of what?

Segment management is all that IW does (in the context of MergePolicy) - it merges them from
time to time, and deletes unused segments. I don't mind if we call it SegmentMaintenacePolicy
to make it more clear. In general I find terms like 'management' not always clarifying what
the object is about, but in this case I think it's not so bad. So if others like the name,
I'm ok with it as well.

bq. how exactly would the MP specified on the IWC interact with the MP passed explicitly to
the merge(MP) method?

Why would they need to interact? I think that the MP passed to IWC should be used for ongoing
merges that IW initiates due to flushing new segments, and the one that you pass to merge()
should do explicit actions, that are usually not done as part of the ongoing merges (like
optimize, expunging deletes etc.).

Mike suggested that we keep MP passed to IWC, and introduce this new class for the explicit
merge() call. I like that idea, even though they will both have similar API signatures: findSegmentsForMerge,
findSegmentsForMaintenance. But, it will also solve Robert's concern -- if we develop an OptimizingMaintenancePolicy,
you cannot pass it to IWC.

Yet, if someone wants to pass such a policy to IWC, he can create a MergePolicy wrapper to
it -- but that is an explicit action someone does and not a naive mistake.
> Consolidate IndexWriter's optimize, maybeMerge and expungeDeletes under one merge(MP)
> --------------------------------------------------------------------------------------------
>                 Key: LUCENE-3569
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/index
>            Reporter: Shai Erera
> Today, IndexWriter exposes 3 methods for 'cleaning up' / 'compacting' / 'optimizing'
your index:
> * optimize() -- merges as much segments as possible (down to 1 segment), and is discouraged
in many cases because of its performance implications.
> * maybeMerge() -- runs 'subtle' merges. Attempts to balance the index by not leaving
too many segments, yet not merging large segments if unneeded.
> * expungeDeletes() -- cleans up deleted documents from segments and on the go merges
> * a default MP that can be set on IndexWriterConfig, for ongoing merges IW performs (i.e.
as a result of flushing a new segment).
> These methods are confusing in several levels:
> * Their names are misleading, see LUCENE-3454.
> * Why does expungeDeletes need to merge segments?
> * Eventually, they really do what the MergePolicy decides that should be done. I.e.,
one could write an MP that always merges all segments, and therefore calling maybeMerge would
not be so subtle anymore. On the other hand, one could write an MP that never merges large
segments (we in fact have several of those), and therefore calling optimize(1) would not end
up with one segment.
> So the proposal is to replace all these methods with a single one merge(MergePolicy)
(more on the names later). MergePolicy will have only one method findSegmentsForMerge and
the caller will be responsible to configure it in order to perform the needed merges. We will
provide ready-to-use MPs:
> * LightMergePolicy -- for setting on IWC and doing the ongoing merges IW executes. This
one will pick segments respecting various parameters such as mergeFactor, segmentSizes etc.
> * HeavyMergePolicy -- for doing the optimize()-style merges.
> * ExpungeDeletesMergePolicy -- for expunging deletes (my proposal is to drop segment
merging from it, by default).
> Now about the names:
> * I think that it will be good, API-backcompat wise and in general, if we name that method
doMaintenance (as expungeDeletes does not have to merge anything).
> * Instead of MergePolicy we call it MaintenancePolicy and similarly its single method
findSegmentsForMaintenance, or getMaintenanceSpecification.
> * I called the MPs Light and Heavy just for the text, I think a better name should be
found, but nothing comes up to mind now.
> It will allow us to use this on 3.x, by deprecating MP and all related methods.

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