[
https://issues.apache.org/jira/browse/CALCITE-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160443#comment-17160443
]
Haisheng Yuan commented on CALCITE-4129:
----------------------------------------
Thanks for your quick response, [~julianhyde].
I don't get it. Can you explain a little bit of {{the approach should be able
to compare RelNode trees without actually building them}}? I thought when we
create the RelNode, we must pass the input relnodes to the RelNode.
If it is in planner, it is OK, we just compare the subset by its identity, no
need to go deeper.
In some cases, we compare the node tree after the best plan is generated.
> Support equality check for whole rel plan tree
> ----------------------------------------------
>
> Key: CALCITE-4129
> URL: https://issues.apache.org/jira/browse/CALCITE-4129
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Haisheng Yuan
> Priority: Major
>
> Currently the only way to check rel node tree deep equality is transforming
> into String by {{RelOptUtil.toString(rel)}} with
> {{SqlExplainLevel.EXPPLAN_ATTRIBUTES}}, which is inefficient. One example is
> RexSubQuery. It has to do it this way, because the rel being reference by
> RexSubQuery is possibly not yet registered to VolcanoPlanner, and the digest
> {{equals}} checks the input RelNode by identity (not content). That is OK for
> RelSubset and HepRelVertex, if the RelNode is already registered in planner,
> but not for plain RelNode that is outside of planner. Due to this, we have to
> implement another set of deep equals logic in our system.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
