[
https://issues.apache.org/jira/browse/CALCITE-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18007641#comment-18007641
]
Stamatis Zampetakis commented on CALCITE-7093:
----------------------------------------------
The {{RelMetadataQuery}} currently relies on {{ThreadLocal}} variables so its
easy to switch between providers whenever you want. In my experience, the join
enumeration is usually performed during a separate optimization phase so it
seems feasible to switch the cost model before/after each phase. I am not
against making the cost function inside the rule configurable I am just trying
to understand the actual need behind the proposal here.
> DPhyp algorithm should accept cost model as parameter
> -----------------------------------------------------
>
> Key: CALCITE-7093
> URL: https://issues.apache.org/jira/browse/CALCITE-7093
> Project: Calcite
> Issue Type: Wish
> Components: core
> Affects Versions: 1.40.0
> Reporter: Mihai Budiu
> Priority: Minor
>
> This is about the hypergraph-based optimization introduced in [CALCITE-6846]
> by [~dongsl].
> The algorithm makes calls to a cost model using getCumulativeCost() (function
> chooseBetterPlan()); the cost model is obtained from the Rel nodes.
> It could be useful to allow add to the the rule configuration an API to
> specify a cost model, similar to the MULTI_JOIN_OPTIMIZE rule
> (LoptOptimizeJoinRule), whose Config has as "withCostFunction" api.
> For example, this would allow the algorithm to emulate bushy join
> optimization using a cost model that optimizes for plan depth.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
