[
https://issues.apache.org/jira/browse/CALCITE-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198440#comment-17198440
]
Vladimir Sitnikov commented on CALCITE-4264:
--------------------------------------------
{quote} 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)
is activated{quote}
Unfortunately, the current cost model is not very well defined when it comes to
"what row cost means".
If row cost means the number of rows processed, then the cost for "limited" and
"unlimited" sort must be different.
Have you seen these threads?
https://lists.apache.org/thread.html/a038e66943b9c4bcb8dfac8130c7d7c9d47b455788af335ba7f202bc%40%3Cdev.calcite.apache.org%3E
https://lists.apache.org/thread.html/90a46d46f9fec715eae0d16d81ae4d95903b01d41f6b793f71ff6220%40%3Cdev.calcite.apache.org%3E
> 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
>
> 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)
