[jira] [Updated] (CALCITE-1842) Wrong order of inputs for makeCost() call in Sort.computeSelfCost()

["Jesus Camacho Rodriguez (JIRA)" <ji...@apache.org>]

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

Jesus Camacho Rodriguez updated CALCITE-1842:
---------------------------------------------
    Fix Version/s: 1.14.0

> 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)