[
https://issues.apache.org/jira/browse/CALCITE-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17676566#comment-17676566
]
Thomas Rebele commented on CALCITE-5470:
----------------------------------------
Thanks to [~rubenql] for finding the following problem in the test:
The toTraits are wrong, instead of
{code:java}
RelTraitSet toTraits =
rel.getCluster().traitSet()
.replace(0, EnumerableConvention.INSTANCE);
{code}
it should say
{code:java}
RelTraitSet toTraits =
rel.getTraitSet().replace(EnumerableConvention.INSTANCE){code}
We do not want to use the trait set from the cluster, as it does not have the
wanted collation.
I had copied the wrong snipped from RelOptRulesTest (appearing in testLimitSort
and testSubQueryWithDynamicStarHang, the former introduced by myself). Maybe
it's better to adapt them to use the rel trait set, to avoid such copy-paste
mistakes.
> VolcanoPlanner removes a necessary sort
> ---------------------------------------
>
> Key: CALCITE-5470
> URL: https://issues.apache.org/jira/browse/CALCITE-5470
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.32.0
> Reporter: Thomas Rebele
> Priority: Major
> Attachments: SortRemoveRule-after.png, SortRemoveRule-before.png,
> planner-viz-data-testSortAndMultiply.js.zip, sqlline.log, test.patch
>
>
> A test case with the VolcanoPlanner produces an unexpected result
> ([^test.patch], applied on 4bebdb07c2f45a95c9a4fdf81e9bcfbdd11a15de). A
> logical plan that roughly corresponds to {{SELECT a*a FROM
> (VALUES(-10),(2),(3)) T(a) ORDER BY a*a}} produces a physical plan that is
> not sorted:
> {noformat}
> logical plan:
> LogicalSort(sort0=[$0], dir0=[ASC])
> LogicalProject($f0=[*($0, $0)])
> LogicalValues(tuples=[[{ -10 }, { 2 }, { 3 }]])
> {noformat}
> The result should be 4, 9, 100.
> {noformat}
> physical plan:
> EnumerableProject($f0=[*($0, $0)])
> EnumerableValues(tuples=[[{ -10 }, { 2 }, { 3 }]]){noformat}
> If I understand the physical plan correctly, its result would be 100, 4, 9.
> Using sqlline gives the correct result (see [^sqlline.log]), so the problem
> could be in the test itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
