You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (Jira)" <ji...@apache.org> on 2021/03/29 00:15:00 UTC
[jira] [Commented] (CALCITE-4558) Sort CPU cost should not incur
per-field copy cost for alignment with filter and project
[ https://issues.apache.org/jira/browse/CALCITE-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310308#comment-17310308 ]
Julian Hyde commented on CALCITE-4558:
--------------------------------------
Can you change the subject from 'Sort' to 'EnumerableSort'? Your comments only apply to in-memory sorts that work by swapping pointers. I don't think we know what is the cost model of these kinds of algorithm. We shouldn't assume that accessing pointers is instantaneous - there will be a wait while they are copied from RAM into cache - so the CPU cost is probably proportional to the number of cells (field values) accessed during the sort.
> Sort CPU cost should not incur per-field copy cost for alignment with filter and project
> ----------------------------------------------------------------------------------------
>
> 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)