[
https://issues.apache.org/jira/browse/CALCITE-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702440#comment-17702440
]
Aitozi commented on CALCITE-5595:
---------------------------------
Hi [~julianhyde] , thanks for your reply.
> I think your assumption that a node has exactly two parents might be rather
> limiting
Actually, I do not assume it has two parents. I write a rule which match on the
{{Spool}} RelNode no matter how many parents it has, usually it should have
more than one parent.
Then during the {{onMatch}} call, I use {{RelOptRuleCall#getParents}} to get
the {{Spool}}'s parents, If they are all Projects, then do the push down.
> 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)
