[
https://issues.apache.org/jira/browse/CALCITE-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702349#comment-17702349
]
Julian Hyde commented on CALCITE-5595:
--------------------------------------
This is an interesting problem. I think your assumption that a node has exactly
two parents might be rather limiting. I wonder if a better solution is to allow
a rule to match two nodes, another node that is the child of both (the Spool in
this case), and perhaps some further children and grandchildren.
Calcites rule matching strategy has been very successful at hiding the details
of the topology of the RelNode graph. This is consistent with that approach.
I will note that some RelNode graph operations do not neatly preserve row type.
For these, we write whole-tree transformations, and do not use RelRule at all.
Field trimming does this. But it has to be done as a separate planning phase,
and doesn’t compose with other rules nicely. So I would take this path only if
the rule-based approach doesn’t apply.
> Support transformParentTo in RelOptRuleCall
> -------------------------------------------
>
> Key: CALCITE-5595
> URL: https://issues.apache.org/jira/browse/CALCITE-5595
> Project: Calcite
> Issue Type: New Feature
> Components: core
> Reporter: Aitozi
> Priority: Major
>
> RelOptRuleCall only supports to produce an equivalent relNode of the current
> root node. But when writing the rule to deal with the Common subExprs. It
> also have to change the current root's parent node.
> For example:
>
> Union
> / \
> Project(b,c) Project(b,d)
> \ /
> Spool
> |
> Scan(a,b,c,d)
>
> Then, with Rule to match on the {{Spool}} , I want to push the unified
> project (b, c, d in this case) down to the {{Spool}} node.
> The parent's of the {{Spool}} node have to adjust the project inputRef
> according to the new produce type of the new Spool.
> To solve this, one way is to use a {{RexShuttle}} to update the inputRef of
> the parents. But it still have to handle the type assertion of
> {{RelOptUtil.verifyTypeEquivalence}} during {{HepRuleCall#transformTo}} .
> Another way is provide a new interface like
> {code:java}
> transformParentTo(RelNode parent, int idx)
> {code}
> So, in the rule, we can create a new parent to transform the old idx parent
> node to the new one.
> I lean to the second way, it looks more flexible and can be integrated to the
> current optimization flow, I have implemented it in our internal version.
> Looking forward to the community's suggestion. Thanks
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
