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