[
https://issues.apache.org/jira/browse/CALCITE-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17026387#comment-17026387
]
Haisheng Yuan commented on CALCITE-3753:
----------------------------------------
[~zabetak]
{quote}
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?
{quote}
It is true that the paper requires top-down. But Calcite is not top-down, it is
even far from Cascades. Calcite already differs them a lot.
{quote}
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?
{quote}
Do you think it will work correctly just by sorting the rule matches to get
requested traits from parents? Without specific control of which group/RelSet
to be executed by topological order, in the physical implementation rule we can
only get part of, not all the requested traits from parent operator, which is
paralyzed. More over, currently there are no APIs for rule to get requested
traits through the manner you said, those who want to achieve this must have
modified the planner code with their own fork. Do we still want to keep
compatibility with those internal code change even if it is not public API?
[~rkondakov] This issue is not related with those problems and space pruning.
It doesn't require those problems to be resolved first, just a minor change on
planner.
> 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)
