[ 
https://issues.apache.org/jira/browse/CALCITE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16075465#comment-16075465
 ] 

Junxian Wu commented on CALCITE-1842:
-------------------------------------

We also encounter this issue when we used Calcite to connect druid. We may want 
this fix sooner so a pull request has been opened in public github repo.

[https://github.com/apache/calcite/pull/491]

Right now test cases are not added yet because I did not find examples that can 
generally check cost before optimization with rules provided by different 
adapters. Please let me know if you have any idea about the test cases that can 
check this fix. Thank you.

> Wrong order of inputs for makeCost() call in Sort.computeSelfCost()
> -------------------------------------------------------------------
>
>                 Key: CALCITE-1842
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1842
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>            Reporter: JD Zheng
>            Assignee: Julian Hyde
>             Fix For: 1.14.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Original code in Sort.java
> {code:java}
> @Override public RelOptCost computeSelfCost(RelOptPlanner planner,
>       RelMetadataQuery mq) {
>     // Higher cost if rows are wider discourages pushing a project through a
>     // sort.
>     double rowCount = mq.getRowCount(this);
>     double bytesPerRow = getRowType().getFieldCount() * 4;
>     return planner.getCostFactory().makeCost(
>         Util.nLogN(rowCount) * bytesPerRow, rowCount, 0);
> {code}
> The last line should be 
> {code:java}
> return planner.getCostFactory().makeCost(
>         rowCount/*rowCount*/, Util.nLogN(rowCount) * bytesPerRow/*cpu*/, 
> 0/*io*/);
> {code}
> The wrong order will make the planner choose the wrong physical plan. For 
> example, if the druid query has a limit of 10 with 10+ dimensions, the 
> optimizer will choose not push the "limit" down to druid instead choose 
> scanning entire data source in druid.
> The fix is very easy, the gain is huge as the performance of the wrong plan 
> is really bad. Hope it will be picked up by the next release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to