mikemccand commented on issue #14148: URL: https://github.com/apache/lucene/issues/14148#issuecomment-2625515650
Oh, that's a neat idea (`MergeScheduler` being able to "cancel" merge choices from `MergePolicy`). I think we would have to register the merge, immediately, on getting it from `MergePolicy`. That's the only thing that prevents `MergePolicy` from e.g. simply picking that merge again. But then, to keep under bandwidth budget, `CMS` could delay actually starting the merge. But, if enough time passes, maybe CMS decides later to then simply cancel (and unregister) the merge? This would kick back those to-be-merged segments into consideration again by the `MergePolicy`, and maybe it picks a different / better merge based on new information? `TieredMergePolicy` does produces merges from "most to least importance", roughly, so if CMS allowed early merges to run, but then delayed/canceled later ones, it could work well -- TMP would reconsider the segments that were lower priority for merging. It would be nice if `MergePolicy` could remain ignorant to bandwidth constraints. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
