You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Chunhui Shi (JIRA)" <ji...@apache.org> on 2018/06/08 06:13:00 UTC
[jira] [Updated] (CALCITE-2356) Allow user defined policy to
dynamically define all or some specific rules' execution order or even skip
some rules
[ 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)