[ https://issues.apache.org/jira/browse/CALCITE-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17377666#comment-17377666 ]
Haisheng Yuan commented on CALCITE-4681: ---------------------------------------- The problem of matching based on traits is that it will match all the operators matching the traits, hence cause more rule matches. I guess what zilin wants is a placeholer, any logical operator is fine, but just match once. I agree that place holder operand is nice to have. > 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)