[
https://issues.apache.org/jira/browse/CALCITE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080198#comment-16080198
]
Jesus Camacho Rodriguez commented on CALCITE-1842:
--------------------------------------------------
[~axeisghost], [~julianhyde], this fix causes three DruidAdapterIT tests to
fail:
{noformat}
Results :
Failed tests:
DruidAdapterIT.testGroupByFloorTimeWithLimit:1884
Expected: a string containing "PLAN=EnumerableLimit(fetch=[3])\n
EnumerableInterpreter\n DruidQuery(table=[[foodmart, foodmart]],
intervals=[[1900-01-09T00:00:00.000/2992-01-10T00:00:00.000]],
projects=[[FLOOR($0, FLAG(MONTH))]], groups=[{0}], aggs=[[]], sort0=[0],
dir0=[DESC])"
but: was "PLAN=EnumerableInterpreter
BindableSort(sort0=[$0], dir0=[DESC], fetch=[3])
DruidQuery(table=[[foodmart, foodmart]],
intervals=[[1900-01-09T00:00:00.000/2992-01-10T00:00:00.000]],
projects=[[FLOOR($0, FLAG(MONTH))]], groups=[{0}], aggs=[[]], sort0=[0],
dir0=[DESC])
"
DruidAdapterIT.testSortLimit:530
Expected: a string containing "PLAN=EnumerableLimit(offset=[2], fetch=[3])\n
EnumerableInterpreter\n DruidQuery(table=[[foodmart, foodmart]],
intervals=[[1900-01-09T00:00:00.000/2992-01-10T00:00:00.000]], projects=[[$39,
$30]], groups=[{0, 1}], aggs=[[]], sort0=[1], sort1=[0], dir0=[ASC],
dir1=[DESC])"
but: was "PLAN=EnumerableInterpreter
BindableSort(sort0=[$1], sort1=[$0], dir0=[ASC], dir1=[DESC], offset=[2],
fetch=[3])
DruidQuery(table=[[foodmart, foodmart]],
intervals=[[1900-01-09T00:00:00.000/2992-01-10T00:00:00.000]], projects=[[$39,
$30]], groups=[{0, 1}], aggs=[[]], sort0=[1], sort1=[0], dir0=[ASC],
dir1=[DESC])
"
DruidAdapterIT.testTopNMonthGranularity:1200
Expected: a string containing "PLAN=EnumerableInterpreter\n
BindableProject(S=[$2], M=[$3], P=[$0])\n DruidQuery(table=[[foodmart,
foodmart]], intervals=[[1900-01-09T00:00:00.000/2992-01-10T00:00:00.000]],
projects=[[$30, FLOOR($0, FLAG(MONTH)), $89]], groups=[{0, 1}], aggs=[[SUM($2),
MAX($2)]], sort0=[2], dir0=[DESC], fetch=[3])"
but: was "PLAN=EnumerableCalc(expr#0..3=[{inputs}], S=[$t2], M=[$t3],
P=[$t0])
EnumerableInterpreter
DruidQuery(table=[[foodmart, foodmart]],
intervals=[[1900-01-09T00:00:00.000/2992-01-10T00:00:00.000]], projects=[[$30,
FLOOR($0, FLAG(MONTH)), $89]], groups=[{0, 1}], aggs=[[SUM($2), MAX($2)]],
sort0=[2], dir0=[DESC], fetch=[3])
"
{noformat}
> 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)
