gsmiller commented on code in PR #13697:
URL: https://github.com/apache/lucene/pull/13697#discussion_r1750898154
##########
lucene/join/src/java/org/apache/lucene/search/join/ToParentBlockJoinQuery.java:
##########
@@ -348,34 +410,23 @@ public void setMinCompetitiveScore(float minScore) throws
IOException {
}
}
- private void setScoreAndFreq() throws IOException {
+ private float scoreChildDocs() throws IOException {
if (childApproximation.docID() >= parentApproximation.docID()) {
- return;
+ return parentScore.score();
}
- double score = scoreMode == ScoreMode.None ? 0 : childScorer.score();
- int freq = 1;
- while (childApproximation.nextDoc() < parentApproximation.docID()) {
- if (childTwoPhase == null || childTwoPhase.matches()) {
- final float childScore = scoreMode == ScoreMode.None ? 0 :
childScorer.score();
- freq += 1;
- switch (scoreMode) {
- case Total:
- case Avg:
- score += childScore;
- break;
- case Min:
- score = Math.min(score, childScore);
- break;
- case Max:
- score = Math.max(score, childScore);
- break;
- case None:
- break;
- default:
- throw new AssertionError();
+
+ float score = 0;
+ if (scoreMode != ScoreMode.None) {
Review Comment:
I'll have to look at the test case a little closer, but I'd rather we didn't
unnecessarily advance to make a test case happy. If there's a much sparser
query clause leading a conjunctive iteration, the eager advancing of the child
iterator to the next parent could add meaningful overhead. I think anyway?
I'm also not totally sure why we even have that check in the TPBJQ logic. It
seems like a slightly odd place to do that check? Maybe there's a different
place we could do that check if necessary? Maybe we could do a check in
`ParentApproximation#advance` to validate that the child iterator doesn't
provide a doc that's present in the parent bitset? Another alternative might be
an `assert` that eagerly advances to the next parent (like you had)? With an
`assert`, we could bypass the potential performance drain while still getting
some validation coverage?
--
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
