[
https://issues.apache.org/jira/browse/CALCITE-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022870#comment-17022870
]
Stamatis Zampetakis commented on CALCITE-3753:
----------------------------------------------
I have a small concern regarding the order of applying the rules mostly related
with the propagation of traits. Let's consider the following plan:
{noformat}
LogicalSort(sort0=[$0], dir0=[ASC])
LogicalProject(DEPTNO=[$8], EMPNO=[$0], MGR=[$3])
LogicalJoin(condition=[AND($8, $7)], joinType=[inner])
LogicalTableScan(table=[[scott, EMP]])
LogicalTableScan(table=[[scott, DEPT]])
{noformat}
If the rules are not applied top-down and it happens to let's say execute the
PhysicalJoinRule before for instance the PhysicalProjectRule how do we know
that the parent has requested a sorting on some attribute to take it into
account in the selection of the join algorithm? I guess you already thought
about such cases so I suppose I am missing something.
On the other hand we have seen in the [dev
list|https://lists.apache.org/thread.html/r7700b2884b24897360ff092dc7d348204101f1f58ac3206d84e0dcf5%40%3Cdev.calcite.apache.org%3E]
that there may be people who would like to apply rules in certain order
(bottom-up/top-down/other) so should we really kill the comparator or should we
try to make the queue configurable?
> 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)
