[
https://issues.apache.org/jira/browse/CALCITE-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17025849#comment-17025849
]
Stamatis Zampetakis commented on CALCITE-3753:
----------------------------------------------
If I am not mistaken, the original Volcano paper explicitly requires the rules
to be executed top-down so that the child knows what traits have been
requested. I know that Calcite varies from the original algorithm (and it
resembles Cascade in quite a few places) but do we want to derive even more?
Currently it is possible (not via the current API) for a PhysicalJoinRule to
know which traits were requested from the parent operator (by looking into the
other subsets of the set that the join belongs) since it was treated first.
From my understanding so far, with the change you are proposing this will not
be possible. What is the correct alternative?
I am not against removing the comparator, I just want to understand if there
are other things that we should tackle before.
> 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
> Attachments: image-2020-01-27-20-27-57-957.png
>
>
> 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)
