JD Zheng created CALCITE-1842:
---------------------------------
Summary: 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
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)
