You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "jin xing (Jira)" <ji...@apache.org> on 2019/10/30 02:48:00 UTC

[jira] [Commented] (CALCITE-3455) Redundant rule firing for both logical and physical nodes

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

jin xing commented on CALCITE-3455:
-----------------------------------

+1 for this Jira and I think there are lots of rules only need to be applied on logical nodes.

> Redundant rule firing for both logical and physical nodes
> ---------------------------------------------------------
>
>                 Key: CALCITE-3455
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3455
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Xiening Dai
>            Assignee: Xiening Dai
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> While I was looking at CALCITE-2970, I noticed that some of the rules are fired for both logical and physical nodes. For example, ProjectMergeRule matches Project.class, so it’s fired for LogicalProject. But then after LogicalProject is converted into EnummerableProject, the same rule is fired again for the physical rels. Same for EnumerableLimitRule, SortRemoveConstantKeysRule, etc. 
> This seems to be unnecessary. When ProjectMerge is applied to LogicalProject nodes, we already generate all possible alternatives with merged projects. We just need to convert the LogicalProject into EnumerableProject. There’s no need to merge EnumerableProject again. 
> If I update those rules to only match logical nodes, the planning time of the case in CALCITE-2970 is reduced ~30%. 



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