[jira] [Commented] (CALCITE-7045) Generate unique correlationId for each correlate node

["suibianwanwan (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17954901#comment-17954901 ] 

suibianwanwan commented on CALCITE-7045:
----------------------------------------

I didn't mark this as a bug. I believe it would work correctly if we can ensure FieldAccess only considers the most recent Correlate with the same correlationId as its scope. But as mentioned in the mailing list, subQuery handling is already complex enough, so we should try to ensure CorId uniqueness whenever possible.

One approach I can think of is to add a parameter to the RelBuilder#join method to determine whether replaceCorrelationId is needed, while maintaining backward compatibility with the existing code in LogicalCorrelate#create. Within Calcite's internal rules, we should ensure that Correlate is always created with the new correlationId.

> 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)