vlsi commented on a change in pull request #2363:
URL: https://github.com/apache/calcite/pull/2363#discussion_r591517936
##########
File path: core/src/main/java/org/apache/calcite/rel/core/Sort.java
##########
@@ -124,11 +126,24 @@ public abstract Sort copy(RelTraitSet traitSet, RelNode
newInput,
@Override public @Nullable RelOptCost computeSelfCost(RelOptPlanner planner,
RelMetadataQuery mq) {
+ double rowCount = mq.getRowCount(this);
+ if (collation.getFieldCollations().isEmpty()) {
+ return planner.getCostFactory().makeCost(rowCount, 0, 0);
+ }
+ final double inCount = mq.getRowCount(input);
// Higher cost if rows are wider discourages pushing a project through a
// sort.
- final double rowCount = mq.getRowCount(this);
final double bytesPerRow = getRowType().getFieldCount() * 4;
Review comment:
I wonder if the cost should account for the number of items in
`getFieldCollations()`.
In other words, it would be nice if `cpu` cost reflected the cost to sort
the items.
Currently, `bytesPerRow` is multiplied by `Math.log` which is wrong.
The better formula should be `heapDepth*comparisonCost` where
`comparisonCost` should be like `collation.getFieldCollations().size()`.
I believe `bytesPerRow` should be eliminated as sort performs NO projection,
and it should be safe to assume sort returns the same input data, so it does
not spend CPU on transformations.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
