[
https://issues.apache.org/jira/browse/CALCITE-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376381#comment-17376381
]
Roman Kondakov commented on CALCITE-4681:
-----------------------------------------
I think this problem may be related to the wrong operand type in
{{JoinAssociateRule}}. It's mapped to {{Join.class}} instead of
{{LogicalJoin.class}} and therefore it is also fired on the newly created
physical nodes like {{EnumerableHashJoin}}. But it's wrong: logical rules
should be fired on the logical nodes only. Try to change the operand type in
{{JoinAssociateRule}} to {{LogicalJoin.class}} and check whether it helps.
> Rule operand match specific shape with or without
> RelSubset.class/RelNode.class
> -------------------------------------------------------------------------------
>
> Key: CALCITE-4681
> URL: https://issues.apache.org/jira/browse/CALCITE-4681
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: ZiLin Chen
> Priority: Major
>
> If we want to match such a pattern, LogicalJoin1 with left Input XXX(original
> LogicalJoin1 left input) and with right input (LogicalJoin.class). we wound
> find that XXX we should use RelNode.class or RelSubset.class. However both
> RelNode.class and RelSubset.class will match all kind of traitSet which is
> inefficient（rule may fires multi time just because of some kind of XXX with
> different trait）, especially when this is a JoinReorder Rule.
> The XXX operand we want to match is exact what LogicalJoin1.getLeft() return.
> LogicalJoin1
> - XXX(original LogicalJoin1 left input)
> - LogicalJoin2
>
> Is that any way we can provide to solve this problem?
> One way maybe changing what RelSubset.class operand match meaning? (Now,
> there is no rule in calcite with RelSubset.class as match operand. Before
> JoinAssociateRule is the only one match RelSubset.class, but change later )
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
