[
https://issues.apache.org/jira/browse/CALCITE-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17199258#comment-17199258
]
Ruben Q L commented on CALCITE-4264:
------------------------------------
I agree it is worth a try. Some simple real-life example where this change
could help:
{code:java}
SELECT * from myTable ORDER BY myField LIMIT 10
{code}
Plan A:
{code:java}
EnumerableLimitSort(collation=myField, fetch=10)
FullScan(table=myTable)
{code}
Plan B:
{code:java}
EnumerableLimit(fetch=10)
IndexScan(table=myTable, collation=myField)
{code}
Both plans are exactly equal in terms of rowCount, however plan B is clearly
better in terms of cost (cpu) since it exploits an index and does not require
to scan the full table. The improvement proposed in the current ticket would
help use choosing the appropriate plan in situations like this.
> 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)
