[jira] [Commented] (CALCITE-4225) Make RelDecorrelator pluggable

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

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

Julian Hyde commented on CALCITE-4225:
--------------------------------------

Let's be careful here. It may be to your organization's benefit that {{RelDecorrelator} is pluggable, but it may not be to Calcite's benefit. For instance, this might make it easier to fork the decorrelator, and now we have different sub-communities operating on different assumptions.

Can we add configuration parameters to {{RelDecorrelator}}? (And add tests each time we add a new parameter.)

Can we make use of planner rules (such as {{RemoveCorrelationForScalarProjectRule}}), and have planner rules be the 'pluggability' mechanism?

> Make RelDecorrelator pluggable
> ------------------------------
>
>                 Key: CALCITE-4225
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4225
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.25.0
>            Reporter: Danny Chen
>            Assignee: Danny Chen
>            Priority: Major
>             Fix For: 1.26.0
>
>
> {{RelDecorrelator}} is our core component that decorrelates the queries. But actually, the pattern it can decorrelate successfully is very limited. And it often causes bug because it decorrelates into a wrong plan (with non-correct sementics).
> When there are bugs there, the downstream project can only wait for the version upgrade (if it is fixed in Calcite master), or they copy the whole Java class and override the Calcite one which is hard to maintain.
> It would be nice if we can make the decorrelation logic pluggable. e.g. we can control how a RelNode was decorrelated(not a coarse-grained flag to turn-on/off the decorrelation).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)