[ https://issues.apache.org/jira/browse/CALCITE-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)