[
https://issues.apache.org/jira/browse/CALCITE-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17913591#comment-17913591
]
Claude Brisson commented on CALCITE-6788:
-----------------------------------------
Customizing the costs via the metadata doesn't allow tweaking the costs for a
specific optimization program. I guess that there are plenty of use cases for
this, in our case it is to anticipate further optimizations that cannot happen
before joins ordering. I will try to provide a test case.
Regarding {{HiveVolcanoPlanner#getCost}}, I read:
> The method extends the logic of the super method to decrease the cost of the
> plan if it contains materialized views (heuristic).
It's pretty clear that Hive would be happy with this change, since this
adjustment would not only apply to the final joins trees candidates but also to
the to-top/push-down costs comparisons, hence potentially producing better
plans.
I emphasis that the goal of this proposal is to provide more consistency to
costs customisations specific to the joins ordering planner. Without it, the
algorithm mixes two distinct costs computations during the process.
> LoptOptimizeJoinRule should delegate costs to optimization planner
> ------------------------------------------------------------------
>
> Key: CALCITE-6788
> URL: https://issues.apache.org/jira/browse/CALCITE-6788
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.38.0
> Reporter: Claude Brisson
> Priority: Major
> Labels: pull-request-available
>
> {{LoptOptimizeJoinRule}} uses costs comparisons to recursively decide whether
> to add a join at the top of the joins tree or to push it down.
> When doing so, instead of directly calling {{mq.getCumulativeCost(rel)}}, it
> should rely on {{call.getPlanner.getCost(rel, mq)}}, which will be used
> thereafter to choose the best joins tree.
> This way, it becomes possible to customize the costs computation during the
> heuristic joins ordering phase by just overriding the {{getCost()}} method of
> the optimization planner.
> Without this patch, it is only possible to alter joins costs at the final
> phase of the algorithm, which defeats the goal of customizing them, including
> during the to-top/push-down phase.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
