Adrien Grand
Adrien Grand
I haven't dug, but your reasoning could explain why we are seeing a similar speedup across both `BEST_SPEED` and `BEST_COMPRESSION` since they benefit from the bulk merging optimization in a...
@uschindler It looks like this benchmark has a noticeable slowdown with this change? https://home.apache.org/~mikemccand/lucenebench/MedTermDayTaxoFacets.html
Apologies @shahrs87 , but after looking more at your changes, I'm getting worried that this change is harder than I had anticipated. I was optimistically hoping that never returning null...
Tangentially, maywe we should think of reviving @dweiss 's #9626. We did not move forward with concurrent merging because this approach used to parallelize across data structures, and usually the...
This indeed! It's a bit manual, but it's what powers nightly benchmarks and what we run to check the performance impact of the changes that we merge.
> This means we can skip more items with this change. Indeed!
I'm not too familiar with the Solr code but I see that it duplicates logic in `setScorer` as well, could it reuse `MultiCollector` directly instead of exposing the method that...
> I think if you run force merge too quick you would still have the same issue if we need to retain the sources. Maybe we should fail `_forcemerge` calls...
I'm closing this PR. Since this PR got opened, we removed threadlocals from `SegmentReader` (#11998) so the number of threadlocal objects no longer scales with the number of open segments,...
This was addressed in https://github.com/apache/lucene/pull/12462.