[
https://issues.apache.org/jira/browse/CALCITE-4522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317871#comment-17317871
]
Ruben Q L commented on CALCITE-4522:
------------------------------------
Thanks for the info [~vladimirsitnikov]. I agree that some of the current cost
computation formulas are questionable in some cases (and directly wrong in
others, like EnumerableHashJoin where it favors joins with smaller LHR, and it
should actually be the opposite).
As a said, since cost is pluggable this is not a blocking issue. In any case,
it seems this topic is clearly larger than the current ticket scope, so I guess
we can leave this ticket as it this, and move the discussion to another thread
/ ticket.
> CPU cost of Sort should be lower if sort keys are empty
> -------------------------------------------------------
>
> Key: CALCITE-4522
> URL: https://issues.apache.org/jira/browse/CALCITE-4522
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: hqx
> Priority: Minor
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 9h 50m
> Remaining Estimate: 0h
>
> The old method to compute the cost of sort has some problem.
> # When the RelCollation is empty, there is no need to sort, but it still
> compute the cpu cost of sort.
> # use n * log\(n) * row_byte to estimate the cpu cost may be inaccurate,
> where n means the output row count of the sort operator, and row_byte means
> the average bytes of one row .
> Instead, I give follow suggestion.
> # the cpu cost is zero if the RelCollation is empty.
> # let heap_size be min(offset + fetch, input_count), and use input_count *
> max(1, log(heap_size))* row_byte to compute the cpu cost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
