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