[
https://issues.apache.org/jira/browse/CALCITE-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933441#comment-17933441
]
Ruben Q L edited comment on CALCITE-6788 at 3/8/25 11:35 AM:
-------------------------------------------------------------
I have created a new PR following the discussion
([https://github.com/apache/calcite/pull/4231] : basically it keeps by default
everything as it was, but it gives the opportunity via rule config to
"override" the method used for cost computations inside the rule. I included a
(forced) unit test showing an example of the impact of this new config
parameter.
Since it should be zero disruptive for the downstream projects using the rule,
I think we can squeeze into 1.39, wdyt?
was (Author: rubenql):
I have created a new PR following the discussion
([https://github.com/apache/calcite/pull/4231)] : basically it keeps by default
everything as it was, but it gives the opportunity via rule config to
"override" the method used for cost computations inside the rule. I included a
(forced) unit test showing an example of the impact of this new config
parameter.
Since it should be zero disruptive for the downstream projects using the rule,
I think we can squeeze into 1.39, wdyt?
> LoptOptimizeJoinRule should be able to delegate costs to the 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
> Assignee: Ruben Q L
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.39.0
>
>
> {{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)
