[
https://issues.apache.org/jira/browse/CALCITE-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17955012#comment-17955012
]
suibianwanwan commented on CALCITE-7045:
----------------------------------------
{quote}One thing to consider though is if the current situation is somehow
convenient for decorrelation or other purposes.
{quote}
For a decorrelator framework, the benefits of having a globally unique
CorrelationId are evident. We only need to maintain a map<Id, RelNode> to
easily locate the scope of all correlated variables.
{quote}have a generator that always generates fresh ids, e.g., using a counter
{quote}
>From what I know, we currently have this method: RelOptCluster#createCorrel.
>However, it is not enforced to be applied during the creation of
>LogicalCorrelate.
> 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)
