[
https://issues.apache.org/jira/browse/CALCITE-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114283#comment-17114283
]
Xiening Dai commented on CALCITE-3455:
--
After adding transformation rule, this is no longer an issue for Enumerable.
But for any other conventions that don't inherit PhysicalNode, there are still
redundant rule firings. Once CALCITE-3972 is resolved, we can create new
physical nodes with the convention specified to avoid additional rule firing.
> 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: 4h 40m
> 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)
