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)
