[
https://issues.apache.org/jira/browse/CALCITE-4557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310474#comment-17310474
]
Vladimir Sitnikov commented on CALCITE-4557:
--------------------------------------------
(quote}Most likely, they all terminate in 1 or 1.1 comparisons on
average.{quote}
If the input is already sorted, then the leading columns would not yield an
early return from the comparisons.
For instance, if the input is already sorted on {{a, b, c}}, then {{sort by a,
b, c, d}} would have to perform 4 comparisons always.
{code:sql}
select *
from (
select a, b, c, d ... inherently ordered by a, b
)
order by a, b, c, d
{code}
---
However, I'm not much into assessing the number of distinct values in the sort
key fields, so I think we should be fine to assume that every next field would
be compared with 0.1 probability decay.
In other words, "sort key comparison cost factor" should be like
{{numberOfPreSortedFieldsInSortKey + 1 * (1 -
0.1^numberOfNonSortedFieldsInSortKey)/(1-0.1)}
> Sort costing should account the number of sort keys: the more keys to
> compare, the more the cost
> ------------------------------------------------------------------------------------------------
>
> Key: CALCITE-4557
> URL: https://issues.apache.org/jira/browse/CALCITE-4557
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.26.0
> Reporter: Vladimir Sitnikov
> Priority: Major
>
> Current costing for sort does not account for the number of keys in the
> comparison function which might result in worse plan selection.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
