[CALCITE-6460] SortRemoveConstantKeysRule fails with AssertionError due to mismatched collation on resulting Sort

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.37.0
• Fix Version/s: 1.38.0
• Component/s: core
• Labels: pull-request-available
• Assignee: Ruben Q L
• Reporter: Ruben Q L
• Created: 09/Jul/24 11:15
• Updated: 17/Oct/24 22:41
• Resolved: 17/Oct/24 22:41

Description

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):

final Sort result =
        sort.copy(sort.getTraitSet(), input, RelCollations.of(collationsList));

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):

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)
...

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:

sql(sql)
        .withVolcanoPlanner(false,  p -> {
            p.addRelTraitDef(RelCollationTraitDef.INSTANCE);
            RelOptUtil.registerDefaultRules(p, false, false);
        })
        .withRule(CoreRules.SORT_REMOVE_CONSTANT_KEYS)
        .check();

Issue Links

• links to: GitHub Pull Request #3850