BiteTheDDDDt opened a new pull request, #65247:
URL: https://github.com/apache/doris/pull/65247
### What problem does this PR solve?
Issue Number: None
Related PR: #62383
Problem Summary:
RQG found a wrong-result case in the OR expansion + anti join + shared scan
shape. A representative query is:
```sql
SET enable_sql_cache = false;
SET enable_runtime_filter_prune = false;
SELECT COUNT(*)
FROM (
SELECT *
FROM table_5 AS t1
LEFT ANTI JOIN table_9 AS t2
ON t1.pk + 0 = t2.pk + 6
OR t1.pk + 1 = t2.pk
INNER JOIN table_20 AS t3
) q;
```
With runtime filters disabled (`SET runtime_filter_type = ''`), the RQG case
returns the expected count `0`. With runtime filters enabled before this fix,
it returned `100`.
The regression was introduced by #62383, which unified runtime filter
generation and changed runtime filters to the v2-style single-target pushdown
path. That made OR-expanded branches create separate runtime filters on CTE
consumers of the same shared producer. In this case the consumers use different
probe expressions after mapping back to the producer, such as `pk + 6` and `pk
- 1`.
The shared CTE producer pushdown only checked that every consumer had a
runtime filter with the same build-side source expression. It did not check
that the consumer probe expressions mapped to the same producer-side target
expression. It then pushed the filter using only the producer slot, losing the
`+ 6` / `- 1` expression difference. As a result, one branch-specific runtime
filter could be applied to the shared scan and affect the other branch, causing
the anti join to return wrong results.
This patch only pushes runtime filters into a shared CTE producer when all
candidate filters map to the same producer-side target expression, and it
preserves that full producer target expression during pushdown.
### Release note
Fix incorrect query results caused by unsafe runtime filter pushdown into
shared CTE producers.
### Check List (For Author)
- Test: Unit Test
- `./run-fe-ut.sh --run
org.apache.doris.nereids.postprocess.RuntimeFilterTest#testPushSharedCteRuntimeFilterOnlyForSameProducerTargetExpression`
- Behavior changed: Yes. The optimizer no longer pushes branch-specific
runtime filters into a shared CTE producer when consumer probe expressions
differ, which restores correct query results.
- Does this need documentation: No
--
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]
