Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-1842

Wrong order of inputs for makeCost() call in Sort.computeSelfCost()

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 1.14.0
    • core
    • None
    • Important

    Description

      Original code in Sort.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);
      

      The last line should be

      return planner.getCostFactory().makeCost(
              rowCount/*rowCount*/, Util.nLogN(rowCount) * bytesPerRow/*cpu*/, 0/*io*/);
      

      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.

      Attachments

        Activity

          People

            julianhyde Julian Hyde
            jdhwlp JD Zheng
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - 1h
                1h
                Remaining:
                Remaining Estimate - 1h
                1h
                Logged:
                Time Spent - Not Specified
                Not Specified