You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (JIRA)" <ji...@apache.org> on 2014/08/17 02:25:18 UTC

[jira] [Resolved] (OPTIQ-343) RelDecorrelator should build its own mappings, not inherit from SqlToRelConverter

     [ https://issues.apache.org/jira/browse/OPTIQ-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Hyde resolved OPTIQ-343.
-------------------------------

    Resolution: Fixed

Fixed in http://git-wip-us.apache.org/repos/asf/incubator-optiq/commit/3055cc32.

> RelDecorrelator should build its own mappings, not inherit from SqlToRelConverter
> ---------------------------------------------------------------------------------
>
>                 Key: OPTIQ-343
>                 URL: https://issues.apache.org/jira/browse/OPTIQ-343
>             Project: Optiq
>          Issue Type: Bug
>            Reporter: Julian Hyde
>            Assignee: Julian Hyde
>
> In order to get an efficient query to generate possible values of the correlation variable, we need to push filters into joins after sql-to-rel conversion but before decorrelation. But pushing filters messes up the mappings that are created by SqlToRelConverter and used by RelDecorrelator.
> Currently Planner.onCopy is used to inform the planner about changes. But it cannot capture what PushFilterThroughJoinRule is doing.
> I think the correct solution is to build the mappings needed by RelDecorrelator based on the current state of the RelNode tree. And re-build, if necessary, when a rule has fired.
> Another benefit: it would be possible to use RelDecorrelator for queries not 



--
This message was sent by Atlassian JIRA
(v6.2#6252)