jimczi commented on code in PR #16220:
URL: https://github.com/apache/lucene/pull/16220#discussion_r3650050055
##########
lucene/core/src/java/org/apache/lucene/search/WANDScorer.java:
##########
@@ -566,17 +566,19 @@ public float score() throws IOException {
@Override
public int advanceShallow(int target) throws IOException {
- // Propagate to improve score bounds
+ // Propagate to sub-scorers. Scorers past target constrain the boundary to
docID - 1.
+ int newUpTo = DocIdSetIterator.NO_MORE_DOCS;
for (Scorer scorer : allScorers) {
- if (scorer.docID() < target) {
- scorer.advanceShallow(target);
+ // Use <= instead of < so we still propagate and use the block boundary
when already at
+ // target.
+ if (scorer.docID() <= target) {
+ newUpTo = Math.min(newUpTo, scorer.advanceShallow(target));
+ } else if (scorer.docID() != DocIdSetIterator.NO_MORE_DOCS) {
+ newUpTo = Math.min(newUpTo, scorer.docID() - 1);
}
}
- if (target <= upTo) {
- return upTo;
- }
- // TODO: implement
- return DocIdSetIterator.NO_MORE_DOCS;
+ // If within the current block, prefer the tighter freshly-computed
boundary.
+ return target <= upTo ? Math.min(upTo, newUpTo) : newUpTo;
Review Comment:
Small question: do we need `upTo` here at all? `newUpTo` is already a valid
boundary on its own (case B forces it below any not-yet-matching scorer, so
everything `getMaxScore` would include was just shallow-advanced to `target`).
Clamping down to the internal `upTo` can only shrink the block and skip less.
Looks like `return newUpTo;` would be simpler and skip more, unless there's a
reason to keep the internal-block fast path I'm missing?
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
