sbroeder opened a new pull request, #4934:
URL: https://github.com/apache/calcite/pull/4934
## Jira Link
[CALCITE-7514](https://issues.apache.org/jira/browse/CALCITE-7514)
## Changes Proposed
`MultiJoinOptimizeBushyRule` crashes with an `AssertionError` when a
`MultiJoin`'s join filters contain a condition that references anything
other than exactly two factors (e.g. a CASE expression spanning three
tables). Such conditions cannot be represented as binary join edges, so
passing them to `createEdge` produced an edge with
`factors.cardinality() != 2`, which violated assertions in the edge
comparator and the greedy ordering loop.
**Fix:** conditions that do not touch exactly two factors are separated
from the edge list before the greedy loop runs. After the join tree is
built, these conditions are remapped from the original `MultiJoin` field
positions to the output positions of the final join tree using
`RexPermuteInputsShuttle`, then applied as a `LogicalFilter` above the
join tree (before the reordering project). For inner joins this is
semantically equivalent to applying them as join predicates.
This also resolves two long-standing TODOs in the class Javadoc:
- *"Join conditions that touch 3 factors."* — fully handled.
- *"Join conditions that touch 1 factor."* — handled defensively (no
crash, correct result); optimal push-down to the scan is left as a
future improvement.
**Reproduction:** the following query previously threw `AssertionError`:
```sql
SELECT e1.ename
FROM emp e1, dept d, emp e2
WHERE e1.deptno = d.deptno
AND e2.deptno = d.deptno
AND d.deptno = CASE WHEN e1.sal > 1000 THEN e2.empno ELSE e1.empno END
A new test testMultiJoinOptimizeBushyThreeFactorCondition in
RelOptRulesTest covers this case.
--
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]
