LIANG751234313 commented on code in PR #65821:
URL: https://github.com/apache/doris/pull/65821#discussion_r3793737129
##########
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:
I checked the MOW case with EXPLAIN, and the actual plan does not keep a
positive score_sort_limit for a SQL-level lone SEARCH on a unique-key MOW table.
For example:
SELECT id, score() AS s
FROM test_search_score_mow_topk_visibility
WHERE search('title:alpha')
ORDER BY s DESC
LIMIT 5;
produces:
SCORE SORT LIMIT: 0
PREDICATES: (search('title:alpha') AND (__DORIS_DELETE_SIGN__ = 0))
So although the SQL text contains only one SEARCH predicate, the scan
predicate is not a lone SEARCH in a unique-key table. Doris injects the hidden
delete-sign predicate, and this PR classifies it as SEARCH plus an extra
predicate, so the early SEARCH Top-K limit is disabled.
I agree that if a unique-key/MOW scan kept a positive score_sort_limit, it
would be unsafe because SEARCH Top-K is evaluated before post-SEARCH visibility
filters such as delete bitmap / delete-sign filtering. But that is not the
actual plan produced by this PR for the MOW case. With SCORE SORT LIMIT: 0, BE
takes the full doc-set collection path instead of
collect_multi_segment_top_k(), and the upper TopN applies the final limit after
visibility filtering.
I also tried to reproduce the deleted-highest-score case on a unique-key
MOW table, comparing the SQL-level lone SEARCH query with a control query that
forces SCORE SORT LIMIT: 0, and both returned the same correct visible rows.
Could you provide a concrete MOW SQL/EXPLAIN where a unique-key MOW lone SEARCH
still produces a positive SCORE SORT LIMIT? Otherwise, this P1 seems to be
based on a plan shape that this PR does not generate.
--
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]
