[
https://issues.apache.org/jira/browse/CALCITE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16076989#comment-16076989
]
Julian Hyde commented on CALCITE-1842:
--------------------------------------
Reviewing now.
> 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)
