[
https://issues.apache.org/jira/browse/CALCITE-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311053#comment-17311053
]
Julian Hyde commented on CALCITE-4558:
--------------------------------------
Your assumption - that the records to be sorted are on a heap and are accessed
via pointers - is not valid for general-purpose sort. Conventional DB sorts use
put records contiguously into blocks of memory. The blocks of memory are
written to disk if the data is larger than available memory, but the same CPU
cost is the same whether or not the blocks are written to disk.
Your cost model may be appropriate for EnumerableSort but is not appropriate
for 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)
