[
https://issues.apache.org/jira/browse/CALCITE-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024825#comment-17024825
]
Haisheng Yuan commented on CALCITE-3753:
----------------------------------------
It has nothing to do with trait propagation. The execution of a rule should not
rely on the execution of another rule, otherwise, it is wrong usage.
Regarding the dev list, first of all, it is a hack to rely on the order to do
the trait propagation. Second, it is most related with the slowness of
optimization, which is also this issue trying to solve. Third, those users in
the dev list already modified the code to have a functionality that neither
current master branch nor this proposal would solve.
> Always try to match and execute substitution rule first and remove rulematch
> ordering
> -------------------------------------------------------------------------------------
>
> Key: CALCITE-3753
> URL: https://issues.apache.org/jira/browse/CALCITE-3753
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Haisheng Yuan
> Priority: Major
>
> In VolcanoPlanner, some rules e.g. ProjectMergeRule, PruneEmptyRule can be
> defined as SubstitutionRule, so that we can always try to match and execute
> them first (without deferring rule call). All the other rulematches doesn't
> need to be sorted and rules can be executed in any order they matched, since
> we are going to execute all of them anyway, sooner or later. Computing and
> comparing importances cause a lot of latency.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
