[
https://issues.apache.org/jira/browse/CALCITE-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021597#comment-17021597
]
Haisheng Yuan commented on CALCITE-3753:
----------------------------------------
A substitution rule is a rule that can generate a single alternative that is
definitely be better than the matched expression. Say ReduceExpressionRule may
generate an alternative better than old one, and can safely replace or even
remove the old one, so that no more rule matches on the old one. The only side
effects I have in my mind is:
Given an operator tree:
{code:java}
A
+-- B
+-- C
{code}
rule1 can match AB and generates a better alternative EF, rule2 can match BC
and generates a better alternative XY. If we apply rule2 first and mark B's
importance as 0, we will not be able to match AB, the alternative EF might be a
better one. I don't have a specific example yet, and don't know it exists or
not. But I think this is a tradeoff, the benefit can outweigh the downsides.
{quote}
You have to have some kind of a queue. Because a rule call might fire several
rules, each of which might fire several rules. I think that firing depth-first
(i.e. using a stack) would have some bad consequences, so we should at least
use a FIFO queue (i.e. breadth-first).
{quote}
It is true. The problem is whenever we add a new RelNode into the RelSet, we
will start matching immediately. But on a second thought, how many recursive
calls will it have for a specific operator? Perhaps very limited.
Maybe we need a specific rule queue for the substitution rule matches, or
always insert these matches into the head of rule match queue so that we can
always pop them first. But this (by deferring rule call) has another side
effects that we will have more rule matches that are turned out to be useless
if the operator is marked 0 importance after some substitution rule.
> 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)
