[
https://issues.apache.org/jira/browse/CALCITE-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702442#comment-17702442
]
Aitozi edited comment on CALCITE-5595 at 3/20/23 4:24 AM:
----------------------------------------------------------
I think if we support transform on the parent nodes in this field trimming
case, the output row type of the parent is not changed.
was (Author: aitozi):
I think if we support transform on the parent nodes in the field trimming, the
output row type is not changed.
> 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)
