[
https://issues.apache.org/jira/browse/CALCITE-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Minogin reassigned CALCITE-7902:
---------------------------------------
Assignee: Andrey Minogin
> Planning fails with "is a PhysicalNode, which is not allowed in
> JoinAssociateRule" when calcite.enable.join.commute=true
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-7902
> URL: https://issues.apache.org/jira/browse/CALCITE-7902
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.42.0
> Reporter: Andrey Minogin
> Assignee: Andrey Minogin
> Priority: Major
> Attachments: JoinChain.java
>
>
> With the documented system property calcite.enable.join.commute=true, the
> default planner fails on an ordinary inner join of three tables:
> {noformat}
> java.lang.RuntimeException:
> rel#226:EnumerableHashJoin.ENUMERABLE.[](left=RelSubset#69,right=EnumerableHashJoin#225,condition==($0,
> $4),joinType=inner) is a PhysicalNode, which is not allowed in
> JoinAssociateRule
> {noformat}
> Setup: Frameworks.getPlanner with Programs.standard() and default rules,
> Calcite 1.42.0, JDK 21. Tables are declared only (row type and row count, no
> data). Query:
> {code:sql}
> SELECT T0.ID AS ID0, T0.C AS C0, T1.ID AS ID1, T1.C AS C1, T2.ID AS ID2, T2.C
> AS C2
> FROM T0 JOIN T1 ON T0.ID = T1.FK JOIN T2 ON T1.ID = T2.FK
> WHERE T0.A > 10 AND T1.A < 900 AND T2.C > 0.5
> {code}
> Self-contained reproducer attached (JoinChain.java, calcite-core only):
> {noformat}
> java -Dcalcite.enable.join.commute=true -cp ... repro.JoinChain 3 false 3
> {noformat}
> Observations:
> - Fails with 3 and 4 tables in the default (non-top-down) mode.
> - Does not fail without the property.
> - Does not fail with calcite.planner.topdown.opt=true.
> - Does not fail when EnumerableMergeJoinRule is removed.
> CoreRules.JOIN_ASSOCIATE is configured withOperandFor(Join.class), so it can
> match a physical join that is already registered in the RelSet, and
> VolcanoRuleCall.transformTo then rejects the result. Configuring the rule
> withOperandFor(LogicalJoin.class) avoids the failure in our runs. The same
> configuration is on main as of 2026-10-27.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)