If I use a simple "AlwaysForceMergePolicy" in a test, I can see that when a run IndexWriter.forceMerge(), the first call to AlwaysForceMergePolicy.findForcedMerges() is done for the MergeTrigger.EXPLICIT. But then, at IndexWriter.merge() line 4531, MergePolicy.findForcedMerges() is called with MergeTrigger.MERGE_FINISHED to merge the segments produced by the output of the first explicit forced merge, and so on. For this degenerated AlwaysForceMergePolicy, the test runs merges in an infinite loop.
Le lun. 20 juin 2022 à 11:11, Adrien Grand <[email protected]> a écrit : > You seem to imply that `forceMerge` runs a cascaded merge where the first > merge creates some new segments that become inputs to a second merge. Have > you considered running a single merge? We had a discussion about cascaded > forced merges and TieredMergePolicy last year and ended up changing > `findForcedMerges` to never run cascaded merges: > https://issues.apache.org/jira/browse/LUCENE-7020. > > On Mon, Jun 20, 2022 at 10:31 AM Bruno Roustant <[email protected]> > wrote: > >> MergePolicy "find merges" methods take a MergeTrigger as parameter, >> except findForcedMerges() and findForcedDeletesMerges(). >> In my use-case, I could leverage a MergeTrigger in findForcedMerges(), >> which can be EXPLICIT or MERGE_FINISHED, to differentiate the merge >> selection between the initial explicit call and the subsequent calls >> triggered after the first merges. >> >> Should we add a MergeTrigger parameter to all MergePolicy "find merges" >> methods for consistency? >> If so, is it an internal or public API? (should this change stay in the >> main branch only) >> > > > -- > Adrien >
