[ 
https://issues.apache.org/jira/browse/LUCENE-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981813#action_12981813
 ] 

Shai Erera commented on LUCENE-2701:
------------------------------------

I don't think we need a useDefaultMaxMergeMb. Instead, we can default the 
member to Long.MAX_VAL. That way, if no one sets it, all segments will be 
considered for merge, and if one wants, he can set it.

I expect that if I use IW with a LMP that sets maxMergeMB, then even if I call 
optimize() this setting will take effect.

BTW, I don't remember introducin this defaul as part of this issue. This issue 
only changed LMP to take the already existed setting into account. So maybe 
reverting this default should be handled within the issue I was changed in?

> Factor maxMergeSize into findMergesForOptimize in LogMergePolicy
> ----------------------------------------------------------------
>
>                 Key: LUCENE-2701
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2701
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>            Reporter: Shai Erera
>            Assignee: Shai Erera
>             Fix For: 3.1, 4.0
>
>         Attachments: LUCENE-2701.patch, LUCENE-2701.patch, LUCENE-2701.patch
>
>
> LogMergePolicy allows you to specify a maxMergeSize in MB, which is taken 
> into consideration in regular merges, yet ignored by findMergesForOptimze. I 
> think it'd be good if we take that into consideration even when optimizing. 
> This will allow the caller to specify two constraints: maxNumSegments and 
> maxMergeMB. Obviously both may not be satisfied, and therefore we will 
> guarantee that if there is any segment above the threshold, the threshold 
> constraint takes precedence and therefore you may end up w/ <maxNumSegments 
> (if it's not 1) after optimize. Otherwise, maxNumSegments is taken into 
> consideration.
> As part of this change, I plan to change some methods to protected (from 
> private) and members as well. I realized that if one wishes to implement his 
> own LMP extension, he needs to either put it under o.a.l.index or copy some 
> code over to his impl.
> I'll attach a patch shortly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to