[ https://issues.apache.org/jira/browse/LUCENE-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791972#comment-16791972 ]
Armin Braun commented on LUCENE-8688: ------------------------------------- [~jpountz] thanks for taking a look. You are right those two points imo. I fixed the first one, by switching the order of the force merge in progress check around to address this point. I left the special case handling though because otherwise the case of merging from a single segments with deletes to a single segment becomes a NOOP when before we'd merge here in any case and expunge the deletes which I guess we want to keep? The second point makes perfect sense to me too, I adjusted the logic to only allow for a max count sized merge or a merge that has 70% of the max size or more for the result (since we jack up the max size by 25% in the beginning of the method, that seemed appropriate but tbh. this number was just a guess). => This should be good for another review now :) > Forced merges merge more than necessary > --------------------------------------- > > Key: LUCENE-8688 > URL: https://issues.apache.org/jira/browse/LUCENE-8688 > Project: Lucene - Core > Issue Type: Bug > Reporter: Adrien Grand > Priority: Minor > Attachments: LUCENE-8688.patch, LUCENE-8688.patch, LUCENE-8688.patch, > LUCENE-8688.patch > > > A user reported some surprise after the upgrade to Lucene 7.5 due to changes > to how forced merges are selected when maxSegmentCount is greater than 1. > Before 7.5 forceMerge used to pick up the least amount of merging that would > result in an index that has maxSegmentCount segments at most. Now that we > share the same logic as regular merges, we are almost sure to pick a > maxMergeAtOnceExplicit-segments merge (30 segments) given that merges that > have more segments usually score better. This is due to the fact that natural > merges assume that merges that run now save work for later, so the more > segments get merged, the better. This assumption doesn't hold for forced > merges that should run on read-only indices, so there won't be any future > merging. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org