Hi Vladimir, I think we should leave it as it was.
The fact that VolcanoCost does not exploit the cpu and io information is a problem of that class and not of the Sort#computeSelfCost method. Note that the VolcanoPlanner can be configured with a RelOptCostFactory which means that people who use the planner may use another implementation of RelOptCost which does take into account cpu and io metrics. Regarding the more general question, I think we should try to make our cost estimations more realistic in terms of cpu and io and don't try to put everything in rows as it is the case for various operators. This of course requires the VolcanoCost to be adapted. Best, Stamatis On Sun, Dec 29, 2019 at 7:33 PM Vladimir Sitnikov < [email protected]> wrote: > Hi, > > I'm inclined to revert > > https://github.com/apache/calcite/commit/48a20668647b5a5e86073ef0e9ce206669ad6867 > Motivation can be found in > > https://issues.apache.org/jira/browse/CALCITE-1842?focusedCommentId=17004696&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17004696 > > WDYT? > > The question there is Sort#computeSelfCost > We have (rows, cpu, io) cost fields, however, most of the time we use just > **rows** to represent the costing. > For instance, EnumerableHashJoin computes the cost and returns (rows, 0, > 0). > > CALCITE-1842 adjusted Sort costing so it moved NLogN to cpu field, and it > makes the sorting virtually free > because the current Volcano is using rows field only when comparing the > costs. > > Unfortunately, CALCITE-1842 has no tests, so I don't really see what was > the problem. > > Vladimir >
