[
https://issues.apache.org/jira/browse/CALCITE-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006806#comment-17006806
]
Ruben Q L commented on CALCITE-3657:
------------------------------------
Since this ticket is modifying the computeSelfCost of EnumerableHashJoin, I
think we could also introduce another factor to make the cost computation more
accurate: the (hash)join condition.
With the implementation of CALCITE-2973, now HashJoin supports all types of
join condition, so we can have three different scenarios:
a) The condition is a "complete equi-join condition"; this is the best case
scenario, the join is performed purely on a hash-based algorithm and no extra
predicate is required.
b) The condition is a "partial equi-join conditiom", i.e. the condition
contains some equi-join items, but also some non-equi-join items; in this case
the join is performed on a hash-based algorithm (for the equi-join items) + an
extra predicate (for the non-equi-join ones).
c) The join condition is a "complete non-equi-join-condition", i.e. there are
no equi-join elements to build a hash-based solution, so the algorithm is
performed based on a predicate which evaluates the whole condition. This is the
worst-case scenario, since the HashJoin actually behaves as a kind of de-facto
nested loop join.
Currently, since the condition nature is not evaluated in the computeSelfCost,
cases a-b-c would have an equivalent cost; I think we should reflect somehow
that: cost a < cost b < cost c
> EnumerableHashJoin should not use NLogN for costing
> ---------------------------------------------------
>
> Key: CALCITE-3657
> URL: https://issues.apache.org/jira/browse/CALCITE-3657
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.21.0
> Reporter: Vladimir Sitnikov
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
