[
https://issues.apache.org/jira/browse/CALCITE-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134321#comment-18134321
]
Andrey Minogin commented on CALCITE-7902:
-----------------------------------------
Root cause, as far as I can tell: the rule is entered through its third operand
(any RelNode) on an AbstractConverter. AbstractConverter is not a PhysicalNode,
so it is registered for transformation rules, but its convention is ENUMERABLE.
VolcanoRuleCall.matchRecurse then filters the other rels of a
TransformationRule match only by convention equality, so EnumerableHashJoin
passes as both the bottom and the top join, and transformTo rejects the copy.
Possible fix: in matchRecurse, also skip PhysicalNode rels for a
TransformationRule, consistent with the checks in
VolcanoPlanner.addRule/onNewClass and in transformTo:
{code:java}
if (operand.getRule() instanceof TransformationRule
&& (rel.getConvention() != previous.getConvention()
|| rel instanceof PhysicalNode)) {
continue;
}
{code}
With this change applied to 1.42.0, the 3-table query plans instead of failing.
The 4-table query with merge join no longer fails either, but takes very long
in the non-top-down mode, which is the CALCITE-7903 problem. I'll prepare a PR
with a test unless someone prefers a different fix.
> 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)
