[
https://issues.apache.org/jira/browse/CALCITE-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17955728#comment-17955728
]
suibianwanwan commented on CALCITE-7045:
----------------------------------------
I agree that we don't have to enforce the creation of a new id every time.
However, at least within certain rules (such as SubQueryRemoveRule), we need to
generate a new CorrelationId when creating Correlate to ensure correctness.
Additionally, to minimize the impact on extensive testing—as [~mbudiu]
suggested—we could add a shuttle at the end of the Planner to increment corId
sequentially from 0..1.
Additionally, perhaps RelOptCluster#createCorrel itself is intended to
generating unique ids?
> 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)
