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 <zabe...@gmail.com> Date: Tuesday, 11. January 2022 at 09:43 To: dev@calcite.apache.org <dev@calcite.apache.org> 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 < j.feina...@pragmaticminds.de> 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 <jhyde.apa...@gmail.com> > Date: Tuesday, 11. January 2022 at 00:38 > To: dev@calcite.apache.org <dev@calcite.apache.org> > 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 <nobigo...@gmail.com> 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. >
