[
https://issues.apache.org/jira/browse/CALCITE-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17250309#comment-17250309
]
Ruben Q L commented on CALCITE-4264:
------------------------------------
Not necessarily [~vladimirsitnikov]. This change just proposes "in case of
equal rowCount, use cpu cost to discriminate".
In my example, both plans would have an equal rowCount cost, so cpu cost would
be used. Of course, we'd require an accurate metadata cost modellization (as
always) to have an representative cpu value. In your example, if an index scan
with a big limit value is actually very expensive, this somehow would need to
be reflected by the cost model, and in that case, the non-index-scan plan
(which we assume would be cheaper in terms of cpu) would be chosen.
> The query planner should take CPU cost into account
> ---------------------------------------------------
>
> Key: CALCITE-4264
> URL: https://issues.apache.org/jira/browse/CALCITE-4264
> Project: Calcite
> Issue Type: Improvement
> Reporter: Thomas Rebele
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Calcite only takes the row count into account when optimizing the queries.
> See [the relevant lines in
> VolcanoCost|https://github.com/apache/calcite/blob/52a57078ba081b24b9d086ed363c715485d1a519/core/src/main/java/org/apache/calcite/plan/volcano/VolcanoCost.java#L98-L116].
> However, two plans might have the same row count, but differ greatly in CPU
> cost. This happens for example when the limit sort rule
> ([CALCITE-3920|https://issues.apache.org/jira/browse/CALCITE-3920]) is
> activated. The row cost is the same, the EnumerableLimitSort only sorts the
> input partially, so has a lower CPU cost.
> Low impact proposal: Compare first the row cost, and only if the row cost is
> equal, compare by CPU cost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
