mikemccand commented on code in PR #13542:
URL: https://github.com/apache/lucene/pull/13542#discussion_r1751974584
##########
lucene/core/src/java/org/apache/lucene/search/TotalHitCountCollectorManager.java:
##########
@@ -28,17 +36,114 @@
*/
public class TotalHitCountCollectorManager
implements CollectorManager<TotalHitCountCollector, Integer> {
+
+ private final boolean hasSegmentPartitions;
+
+ /**
+ * Creates a new total hit count collector manager. The collectors returned
by {@link
+ * #newCollector()} don't support intra-segment concurrency. Use the other
constructor if segments
+ * partitions are being searched.
+ */
+ public TotalHitCountCollectorManager() {
+ this(false);
+ }
+
+ /**
+ * Creates a new total hit count collector manager, providing a flag that
signals whether segment
+ * partitions are being searched, in which case the different collector need
to share state to
+ * ensure consistent behaviour across partitions of the same segment. There
are segment partitions
+ * when the {@link IndexSearcher#slices(List)} methods returns leaf slices
that target leaf reader
+ * partitions.
+ *
+ * @see IndexSearcher#slices(List)
+ * @see org.apache.lucene.search.IndexSearcher.LeafReaderContextPartition
+ * @param hasSegmentPartitions whether the collector manager needs to create
collectors that
+ * support searching segment partitions in parallel (via intra-segment
search concurrency)
+ */
+ public TotalHitCountCollectorManager(boolean hasSegmentPartitions) {
Review Comment:
> I made the change to accept a `LeafSlice[]` in the constructor instead of
a boolean. That feels more automatic, although not perfect :)
I think this is better -- there is no more trap, since the
`CollectorManager` now "does the right thing" if there are partitions in the
`LeafSlice[]`, or not.
We can improve it later (post 10.0.0) ... ideally, somehow, `IndexSearcher`
would share the slices with the `CollectorManager` up front to inform it. Or,
we can optimize enough for the "might contain partitions" case and just use
that code path always (better). But let's not block this awesome first step
with this "optimization drives API" wrinkle...
--
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
