[
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)