[
https://issues.apache.org/jira/browse/CALCITE-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17955423#comment-17955423
]
Julian Hyde commented on CALCITE-7045:
--------------------------------------
A significant downside to generating unique ids is that planning will become
non-repeatable.
So let’s not imagine this is a panacea. It will have downsides that we don’t
know about yet, but can probably predict. I would spend more effort to make
the current “relative path” scheme work.
Note that the same design choice exists for column identifiers. Calcite uses
ordinals - relative to the input(s) and repeatable- and Spark’s Catalyst uses
UUIDs. Sparks scheme works well until it doesn’t - such as when you merge plans
due to materialized view expansion or self-join - and at that time it fails
badly.
> Generate unique correlationId for each correlate node
> -----------------------------------------------------
>
> Key: CALCITE-7045
> URL: https://issues.apache.org/jira/browse/CALCITE-7045
> Project: Calcite
> Issue Type: Improvement
> Reporter: suibianwanwan
> Priority: Major
>
> As discussed in
> [https://lists.apache.org/thread/l5ls7hxmrkp6vqqmffxs4cq4dnv95x36] :
> Currently in SubQueryRemove, new Correlates are created based on the
> CorrelationId from the original RelNode. When this subQuery requires multiple
> Correlate expansions or when multiple subQueries share the same CorrelationId
> and are expanded separately, multiple Correlates with identical CorrelationId
> may be generated.
> This can cause difficulties during Decorrelate processing and lead to errors
> in some scenarios.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
