rmuir commented on code in PR #11738:
URL: https://github.com/apache/lucene/pull/11738#discussion_r966338760
##########
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:
right, whereas before we'd always iterate all the terms/postings in
sequential order. i feel here that the optimization is being too-invasive on
the typical case? e.g. on a big index with a MTQ that matches many terms, we
may suffer page faults and stuff going back to those first 16 terms, when it
can be avoided.
--
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
