Adrien Grand

Thank you @mikemccand !

`PointRangeQuery` bottlenecks of adding doc IDs to a bit set rather than on comparisons, so I wonder if this optimization really helps in practice. On your benchmark run, I see...

It looks like this: 

It looks like both options 1 and 2 try to dynamically update the number of merge threads based on multi-tenancy, option 1 does it from the outside via a manager,...

I have similar questions, but I think we can figure them out? We have options like running merges in the indexing thread (a la SerialMergeScheduler) when that would help. IMO...

Yes, this is the same idea indeed! I had thumbs-up'ed it. :) But then the discussion went back to iterating on CMS, which feels both more complicated (N-N feedback loops...

EDIT: at the time of this comment, only `TopScoreDocCollector` no longer used `HitsThresholdChecker`. wikibigall with a `searchConcurrency` of 8 suggests that the slowdown is tiny: ``` TaskQPS baseline StdDevQPS my_modified_version...

Actually, while I was at it, I also removed `TopFieldCollector`'s dependency on HitsThresholdChecker, and then removed `HitsThresholdChecker`. ``` TaskQPS baseline StdDevQPS my_modified_version StdDev Pct diff p-value And2Terms2StopWords 189.12 (4.5%) 182.81...

Wow, it's been a bigger speedup on nightly benchmarks than on my machine: https://benchmarks.mikemccandless.com/And3Terms.html.

Your suggestion is how it used to work before: https://github.com/apache/lucene/pull/12499/files#diff-e744fc99cb74627f02e30c1cbda56dede66d2ecdfd57db2ce869b9a9a43fa41cR49-R64. The context switching isn't great indeed, but executing some tasks on the current thread makes it hard to correctly reason...