[jira] [Updated] (CALCITE-4558) Sort CPU cost should be aligned with filter and project: sort should not incur per-field copy cost

["Vladimir Sitnikov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Sitnikov updated CALCITE-4558:
---------------------------------------
    Summary: Sort CPU cost should be aligned with filter and project: sort should not incur per-field copy cost  (was: Sort CPU cost should be aligned with filter and project: sort should not incur row copy cost)

> Sort CPU cost should be aligned with filter and project: sort should not incur per-field copy cost
> --------------------------------------------------------------------------------------------------
>
>                 Key: CALCITE-4558
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4558
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.26.0
>            Reporter: Vladimir Sitnikov
>            Priority: Major
>
> Typical Java implementations of the sort do not copy rows (they copy references only), so 
> it makes little sense to have "row width" as the key driver of the sort costing.
> The CPU cost for filter does not include "row copy" cost.
> Even though the implementations might be different, in-core costs should be aligned.
> For instance, the current, EnumerableLimitSort and EnumerableSort have bytesPerRow multiplier, however, the implementation does not copy rows field-by-field .



--
This message was sent by Atlassian Jira
(v8.3.4#803005)