[
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:53 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. If we compare the costs of
the two plans, the plans must return equivalent results. So they must have the
same estimations of the rows.
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
> 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)
