[
https://issues.apache.org/jira/browse/CALCITE-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17250343#comment-17250343
]
Ruben Q L commented on CALCITE-4264:
------------------------------------
I agree with you [~vladimirsitnikov]. From my point of view (not DB expert)
using rowCount for cost comparison seems odd, but that is the current behavior
of Volcano cost. We could open that discussion (in a separate ticket), but that
would be a deeper, more drastic change. That is not the purpose of the current
ticket: here it is proposed a simple adjustment (evolution?) in the current
Volcano cost mechanism: keep rowCount verification, but in case of tie, use cpu.
> 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)
