gsmiller commented on code in PR #11738:
URL: https://github.com/apache/lucene/pull/11738#discussion_r966335478
##########
lucene/core/src/java/org/apache/lucene/search/MultiTermQueryConstantScoreWrapper.java:
##########
@@ -179,8 +189,29 @@ private WeightOrDocIdSet rewrite(LeafReaderContext
context) throws IOException {
return new WeightOrDocIdSet(weight);
}
- // Too many terms: go back to the terms we already collected and start
building the bit set
+ // Too many terms: we'll evaluate the term disjunction and populate a
bitset. We start with
+ // the terms we haven't seen yet in case one of them matches all docs
and lets us optimize
+ // (likely rare in practice):
Review Comment:
The difference in the ordering change is just that we'll start building our
bitset from the 17th term onwards and then come back and "fill in" the first
16. We still iterate the query-provided terms a single time in the order
they're provided, it's just a question of when we go back to "fill in" those
first 16 (do we "pause" after hitting the 17th term to fill in the first 16 the
pick back up, or do we continue on and come back).
Do you suspect a performance shift or some other impact if we tweak this? I
don't have a strong opinion.
--
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
