You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Vladimir Sitnikov (Jira)" <ji...@apache.org> on 2020/12/16 13:52:00 UTC
[jira] [Comment Edited] (CALCITE-4264) The query planner should
take CPU cost into account
[ https://issues.apache.org/jira/browse/CALCITE-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17250328#comment-17250328 ]
Vladimir Sitnikov edited comment on CALCITE-4264 at 12/16/20, 1:51 PM:
-----------------------------------------------------------------------
They should return the same results, shouldn't they?
Why use "rows" as the primary comparison tool then? The rows must always be equal, and any inequality of the cardinality estimation means there's a bug.
In other words, if "plan a" produces the same data as "plan b", then the estimation of the resulting rows must be the same.
That makes it weird to use "rows" as the primary comparison value
was (Author: vladimirsitnikov):
They should return the same results, shouldn't they?
Why use "rows" as the primary comparison tool then? The rows must always be equal, and any inequality of the cardinality estimation means there's a bug.
In other words, if "plan a" produces the same data as "plan b", then the estimation of the resulting rows must be the same.
That makes it weird to use "rows" as the primary comparison value.omparison value.
> 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)