You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by jp...@apache.org on 2023/02/27 18:05:33 UTC

[lucene] 01/02: Remove LogMergePolicy's boundary at the floor level. (#12113)

This is an automated email from the ASF dual-hosted git repository.

jpountz pushed a commit to branch branch_9x
in repository https://gitbox.apache.org/repos/asf/lucene.git

commit ba32642e66a6fac64ee32148e1f145fc1e19946d
Author: Adrien Grand <jp...@gmail.com>
AuthorDate: Mon Feb 27 17:38:34 2023 +0100

    Remove LogMergePolicy's boundary at the floor level. (#12113)
    
    `LogMergePolicy` has this boundary at the floor level that prevents merging
    segments above the minimum segment size with segments below this size. I cannot
    see a benefit from doing this, and no tests fail if I remove it, while this
    boundary has the downside of not running merges that seem legit to me. Should
    we remove this boundary check?
---
 lucene/core/src/java/org/apache/lucene/index/LogMergePolicy.java | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/lucene/core/src/java/org/apache/lucene/index/LogMergePolicy.java b/lucene/core/src/java/org/apache/lucene/index/LogMergePolicy.java
index f78833acded..f7c5011d9c6 100644
--- a/lucene/core/src/java/org/apache/lucene/index/LogMergePolicy.java
+++ b/lucene/core/src/java/org/apache/lucene/index/LogMergePolicy.java
@@ -554,11 +554,6 @@ public abstract class LogMergePolicy extends MergePolicy {
         // With a merge factor of 10, this means that the biggest segment and the smallest segment
         // that take part of a merge have a size difference of at most 5.6x.
         levelBottom = (float) (maxLevel - LEVEL_LOG_SPAN);
-
-        // Force a boundary at the level floor
-        if (levelBottom < levelFloor && maxLevel >= levelFloor) {
-          levelBottom = levelFloor;
-        }
       } else {
         // For segments below the floor size, we allow more unbalanced merges, but still somewhat
         // balanced to avoid running into O(n^2) merging.