Hi Julian, Could you please check if your RelRoot.collation has the expected value? I would expect it to be [$0 DESC]. If the value is correct, you may add it to the "desired" trait set: "desired.replace(root.collation)". Hopefully, this should help.
Regards, Vladimir. вт, 11 янв. 2022 г. в 16:47, Julian Feinauer <[email protected]>: > Hey Vladimir, > > when this issue appeared it was > > RelTraitSet desired = cluster.traitSet() > .replace(BindableConvention.INSTANCE); > > RelNode expectedRoot = planner.changeTraits(root, desired); > planner.setRoot(expectedRoot); > > And then > > > RelNode exp = planner.findBestExp(); > > So the root node had no sorting „requirement”. > But from my understanding of the SortRemoveRule it does remove the Sort > and at the same time adds the respective CollationTrait to the input node. > In my case this was a LogicalProject. > I have no idea how the Project itself then assures that the CollationTrait > is fulfilled. > > By the way, is there a way to shot the Traits from a RelNode Tree? This > could help to analyze this kind of situations? > > Thanks! > Julian > > > > From: Vladimir Ozerov <[email protected]> > Date: Tuesday, 11. January 2022 at 14:09 > To: [email protected] ([email protected]) < > [email protected]> > Subject: Re: Sort getting removed during optimization > Hi Julian, > > When invoking the optimizer, you may provide the desired trait set of the > top-level node. It might happen, that the specific collation is not > requested from the optimizer, and hence the plan with a top-level Sort > operator is not chosen. Could you please show how you invoke the planner? > > Regards, > Vladimir. > > вт, 11 янв. 2022 г. в 12:44, Julian Feinauer <[email protected] > >: > > > Hey Stamatis, > > > > yes, thats why I looked it up at first… the results are wrong : ) > > So both tables for themselves are sorted but the Full Join is finally two > > blocks. The Left Join (sorted like the left rel) and then the remaining > > entries from the right side (also ordered). But overall not ordered. > > > > Best > > Julian > > > > From: Stamatis Zampetakis <[email protected]> > > Date: Tuesday, 11. January 2022 at 09:43 > > To: [email protected] <[email protected]> > > Subject: Re: Sort getting removed during optimization > > Hi Julian F, > > > > Quite a naive question but did you get wrong results from the given > plan? A > > missing sort is not necessarily problematic. > > > > I hope I am not saying something stupid but I think there are cases > where a > > full join algorithm can retain the order of some of its inputs. > > > > Best, > > Stamatis > > > > On Tue, Jan 11, 2022 at 8:30 AM Julian Feinauer < > > [email protected]> wrote: > > > > > Hi Julian, Xiong, > > > > > > thanks for your fast replies! > > > > > > So first, the default Rules were registered: > > > > > > planner = new VolcanoPlanner(); > > > RelOptUtil.registerDefaultRules(planner, false, true); > > > > > > And as traits I used: > > > > > > planner.addRelTraitDef(ConventionTraitDef.INSTANCE); > > > planner.addRelTraitDef(RelCollationTraitDef.INSTANCE); > > > > > > I digged a bit deeper and what was triggered was the `SortRemoveRule`. > > > If I disabled the Collation Trait this did no longer happen and all > > worked. > > > > > > I will later try to get a MWE done to reproduce this, if this is a bug. > > > Because the bug would then either be the Full Join producing a wrong > > > Collation or the SortRemoveRule investigating the input Collation > wrong, > > or? > > > > > > But nonetheless, thank you very much! > > > Julian > > > > > > From: Julian Hyde <[email protected]> > > > Date: Tuesday, 11. January 2022 at 00:38 > > > To: [email protected] <[email protected]> > > > Subject: Re: Sort getting removed during optimization > > > Is it possible that the Sort is being removed because some component > > knows > > > that the input is already sorted? > > > > > > In particular, if a relation has at most one row, it is always sorted. > > > Maybe the planner is deducing this via a some row-count metadata or > > > uniqueness constraint. > > > > > > > > > > On Jan 10, 2022, at 3:35 PM, xiong duan <[email protected]> wrote: > > > > > > > > If I understand correctly, If we remove the BINDABLE_SORT_RULE, the > > > > result will throw an exception about the Plan transformation. So it > > > looks > > > > like a wrong rule's result. If you don't customize the rule, It is a > > bug, > > > > and please test this using Calcite's new version. > > > > > >
