github-actions[bot] commented on code in PR #65821:
URL: https://github.com/apache/doris/pull/65821#discussion_r3804421559
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/rules/rewrite/PushDownScoreTopNIntoOlapScan.java:
##########
@@ -239,6 +243,19 @@ private Plan pushDown(
return topN.withChildren(newProject);
}
+ private boolean shouldDisableSearchTopN(Set<Expression> conjuncts,
Expression extractedScorePredicate) {
+ List<Expression> nonScoreConjuncts = conjuncts.stream()
+ .filter(conjunct -> extractedScorePredicate == null ||
!conjunct.equals(extractedScorePredicate))
+ .collect(ImmutableList.toImmutableList());
+
+ boolean hasSearchPredicate = nonScoreConjuncts.stream()
+ .anyMatch(conjunct -> !conjunct.collect(e -> e instanceof
SearchExpression).isEmpty());
+ if (!hasSearchPredicate) {
+ return false;
+ }
+ return nonScoreConjuncts.size() > 1 || !(nonScoreConjuncts.get(0)
instanceof SearchExpression);
Review Comment:
The MOW plan is protected by the injected delete-sign predicate, but that
does not close the broader visibility concern. `DUP_KEYS` provides a concrete
counterexample because those tables do not receive `__DORIS_DELETE_SIGN__`.
For example, insert two SEARCH-matching rows where id 1 scores above id 2,
then execute `DELETE FROM t WHERE id = 1`. The later score query still has the
reduced plan
```text
TopN(score DESC, LIMIT 1)
Project(id, score() AS score)
Filter(search('title:alpha'))
Scan(DUP_KEYS table)
```
so this helper keeps `SCORE SORT LIMIT: 1`. BE attaches the legacy delete
predicate to older rowsets in `BetaRowsetReader`, but SEARCH consumes
`IndexQueryContext::query_limit` first in `function_search.cpp`; exact
`delete_condition_predicates` evaluation happens later in
`SegmentIterator::_evaluate_short_circuit_predicate()`. The deleted high scorer
therefore consumes Top-1 and is then removed, while the live runner-up was
never collected.
Please account for storage delete predicates (and any other late semantic
mask) before retaining positive SEARCH Top-K, and add a deleted-highest-score
DUP_KEYS regression. I am replying here instead of opening another inline
thread because this is concrete evidence for the same invariant already raised
above.
--
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]
