[
https://issues.apache.org/jira/browse/CALCITE-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130294#comment-18130294
]
Vladimir Sitnikov commented on CALCITE-3455:
--------------------------------------------
CALCITE-3997 (commit 7be30db36d, 1.23.0) fixed this for Enumerable rels. It
added {{TransformationRule}}, and {{VolcanoPlanner}} does not match such rules
against {{PhysicalNode}} rels. {{ProjectMergeRule}},
{{FilterProjectTransposeRule}}, and {{SortRemoveConstantKeysRule}} implement
it, so in {{VolcanoPlanner}} they no longer fire on Enumerable rels. With the
default rule set, {{EnumerableLimitRule}} matches only {{EnumerableSort}} among
physical rels, and its {{onMatch}} returns at once there because
{{EnumerableSort}} never has a fetch or offset.
Redundant firing remains for conventions whose rel interface does not extend
{{PhysicalNode}}, such as {{JdbcRel}} and {{BindableRel}}. Such a convention
can avoid it by extending {{PhysicalNode}}, or a user can register a
logical-only instance built from the rule's config (CALCITE-3923, 1.25.0), for
example
{{ProjectMergeRule.Config.DEFAULT.withOperandFor(LogicalProject.class).toRule()}}.
The JDBC case is tracked in CALCITE-7876.
PR [#1543|https://github.com/apache/calcite/pull/1543] is closed for the same
reason.
> 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
(v10.3.26#10030026)
