[
https://issues.apache.org/jira/browse/CALCITE-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17013420#comment-17013420
]
Vladimir Sitnikov commented on CALCITE-2356:
--------------------------------------------
{quote} Long story short: we can skip
optimization of some RelNodes if it is known that it's children have the
bigger cost than the best RelNode in the same Subset{quote}
Does it suggest we should refrain from using `infinite` costs?
It might be relevant to
https://docs.optaplanner.org/7.0.0.Beta1/optaplanner-docs/html/ch05.html#scoreTrap
{quote}Always specify the degree of infeasibility. The business will often say
"if the solution is infeasible, it does not matter how infeasible it is." While
that is true for the business, it is not true for score calculation as it
benefits from knowing how infeasible it is. In practice, soft constraints
usually do this naturally and it is just a matter of doing it for the hard
constraints too.{quote}
Of course, the case with Calcite is slightly different, however, with Logical
relations, it is hard to weigh options as all the relations have the same costs.
> 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
> 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
(v8.3.4#803005)
