LIANG751234313 commented on code in PR #65821:
URL: https://github.com/apache/doris/pull/65821#discussion_r3818135853
##########
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:
This PR is scoped to the case where SEARCH is combined with other
planner-visible predicates in the same FE plan, and the Top-K limit may be
applied before those remaining predicates are evaluated. The DUP_KEYS + DELETE
case is a separate storage-side visibility problem: the delete predicate is
applied later than the SEARCH Top-K limit, so the FE rewrite in this PR cannot
safely reason about it in the same way.
I’ve filed a separate JIRA to track that broader bug:
http://jira.selectdb-in.cc/browse/DORIS-28025.
--
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]
