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