Atri, Julian, Thank you very much for your responses. Is there a chance that this rule will make it into the upcoming 1.13.0 release?
Mike On Tue, Jun 27, 2017 at 4:17 PM, Julian Hyde <[email protected]> wrote: > > Atri Sharma wrote: > > > > but have hit a bug in HepPlanner which Julian is looking into. > > For the record, I am not actively looking into the bug. > > > Michael Alexeev wrote: > > > > Is SortRemoveRule supposed to address this - Planner rule to remove Sort > if > > its input is already sorted. > > > > Looking at its onMatch implementation, I don't see that it actually > > compares the Sort and its input node collations. What if they are > > different? It only checks whether a planner has a RelCollationSet or not. > > SortRemoveRule doesn't exactly "remove" the sort. It looks at "Sort(r, > x ASC, y DESC)" and says "If I had a version of r that was sorted on x > ASC, y DESC, that would do fine". Now, if r happens to be, say, a > TableScan already sorted on "x ASC, y DESC", then we are in luck. If r > is sorted on "x ASC", then we can make do with a partial sort. > > It is actually doing something very powerful and subtle. It converts a > verb "please sort r", into an adjective "give me a sorted r". > > > A follow up question - how/when/where this set is getting set in the > > planner? > > If you mean how are collations deduced, the answer is > RelMetadataQuery.collations(RelNode). There are several "collation" > methods in RelMdCollation, but you can also add your own providers. > > Julian >
