[
https://issues.apache.org/jira/browse/CALCITE-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18008456#comment-18008456
]
Silun Dong edited comment on CALCITE-7093 at 7/20/25 12:41 PM:
---------------------------------------------------------------
Is this the case you are referring to:
{code:java}
HyperGraph // Optimizing with dphyp
RelNode
RelNode
RelNode
HyperGraph
......{code}
If I understand correctly, this can be avoided by simply applying the rule in
HepPlanner with the BOTTOM_UP matching order. HyperGraph is a node to be
optimized, so it may be meaningless to consider its cost.
was (Author: JIRAUSER308615):
Is this the case you are referring to:
{code:java}
HyperGraph // Optimizing with dphyp
RelNode
RelNode
RelNode
HyperGraph
......{code}
If I understand correctly, I think we can do the following:
# When using DphypJoinReorderRule, the best matching order of HepPlanner is
BOTTOM_UP, and the above case should not occur.
# Rewrite the {{estimateRowCount}} and {{computeSelfCost}} methods for
HyperGraph (for simplicity, it can be consistent with the original Join).
However, HyperGraph is a node to be optimized, so it is meaningless to consider
its cost. It may be sufficient to optimize it by BOTTOM_UP.
> 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)
