[
https://issues.apache.org/jira/browse/CALCITE-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chunhui Shi updated CALCITE-2356:
---------------------------------
Description:
We have seen the order of the rule execution did impact VolcanoPlanner's
behavior, for example, in CALCITE-2223, if we reverse the order decided by name
in RuleMatchImportanceComparator, we could get different result for
CALCITE-2223 case.
And in some of our practices, we have seen rules on overlapped patterns could
also trigger unnecessary chaos and much bigger exploration space which caused
the planning time became much longer.
So the proposal of this Jira is, while each rule focuses on the local pattern,
Calcite allow a pluggable coordinator of rule execution to utilize the
knowledge we have about the rules and current state. The output of this
coordinator is the sequence of rules to execute on matching patterns. The input
is still the matching rules and pattern discovered by Calcite. When new nodes
added and new rules need to be triggered, they should be added through the
coordinator to decide whether/how they will be executed.
This proposed feature should not impact any current Calcite users since they
don't define their own policies.
was:
We have seen the order of the rule execution order did impact VolcanoPlanner's
behavior, for example, in CALCITE-2223, if we reverse the order decided by name
in RuleMatchImportanceComparator, we could get different result for
CALCITE-2223 case.
And in some of our practices, we have seen rules on overlapped patterns could
also trigger unnecessary chaos and much bigger exploration space which caused
the planning time became much longer.
So the proposal of this Jira is, while each rule focuses on the local pattern,
Calcite allow a pluggable coordinator of rule execution to utilize the
knowledge we have about the rules and current state. The output of this
coordinator is the sequence of rules to execute on matching patterns. The input
is still the matching rules and pattern discovered by Calcite. When new nodes
added and new rules need to be triggered, they should be added through the
coordinator to decide whether/how they will be executed.
This proposed feature should not impact any current Calcite users since they
don't define their own policies.
> Allow user defined policy to dynamically define all or some specific rules'
> execution order or even skip some rules
> -------------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-2356
> URL: https://issues.apache.org/jira/browse/CALCITE-2356
> Project: Calcite
> Issue Type: Bug
> Reporter: Chunhui Shi
> Assignee: Julian Hyde
> Priority: Major
>
> We have seen the order of the rule execution did impact VolcanoPlanner's
> behavior, for example, in CALCITE-2223, if we reverse the order decided by
> name in RuleMatchImportanceComparator, we could get different result for
> CALCITE-2223 case.
> And in some of our practices, we have seen rules on overlapped patterns could
> also trigger unnecessary chaos and much bigger exploration space which caused
> the planning time became much longer.
> So the proposal of this Jira is, while each rule focuses on the local
> pattern, Calcite allow a pluggable coordinator of rule execution to utilize
> the knowledge we have about the rules and current state. The output of this
> coordinator is the sequence of rules to execute on matching patterns. The
> input is still the matching rules and pattern discovered by Calcite. When new
> nodes added and new rules need to be triggered, they should be added through
> the coordinator to decide whether/how they will be executed.
> This proposed feature should not impact any current Calcite users since they
> don't define their own policies.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
