Ruben Q L created CALCITE-6460: ---------------------------------- Summary: SortRemoveConstantKeysRule fails with AssertionError due to mismatched collation on resulting Sort Key: CALCITE-6460 URL: https://issues.apache.org/jira/browse/CALCITE-6460 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.37.0 Reporter: Ruben Q L Assignee: Ruben Q L Fix For: 1.38.0
When {{SortRemoveConstantKeysRule}} is applied, at the end of the process it creates the resulting Sort with the new collation (which has removed the constant keys from the original one): {code} final Sort result = sort.copy(sort.getTraitSet(), input, RelCollations.of(collationsList)); {code} However, if there's a collation defined inside's the Sort's traitSet, this copy will fail, because there will be a mismatch between the (original) collation in the traitSet (which is unchanged at the moment of the copy) and the new collation that has been computed by the rule (removing constant keys): {noformat} traits=NONE.[1, 2 DESC], collation=[2 DESC] java.lang.AssertionError: traits=NONE.[1, 2 DESC], collation=[2 DESC] at org.apache.calcite.rel.core.Sort.<init>(Sort.java:87) at org.apache.calcite.rel.logical.LogicalSort.<init>(LogicalSort.java:48) at org.apache.calcite.rel.logical.LogicalSort.copy(LogicalSort.java:81) at org.apache.calcite.rel.core.Sort.copy(Sort.java:150) at org.apache.calcite.rel.rules.SortRemoveConstantKeysRule.onMatch(SortRemoveConstantKeysRule.java:85) ... {noformat} This problem only happens if the traitSet includes {{RelCollationTraitDef.INSTANCE}}, so it can be unnoticed in many cases. However, we can reproduce it by adjusting {{RelOptRulesTest#testSortRemovalOneKeyConstant}}: {code} sql(sql) .withVolcanoPlanner(false, p -> { p.addRelTraitDef(RelCollationTraitDef.INSTANCE); RelOptUtil.registerDefaultRules(p, false, false); }) .withRule(CoreRules.SORT_REMOVE_CONSTANT_KEYS) .check(); {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)