Zero chance of it being in 1.13.0. That release is done and dusted. (Jesus will officially announce it very shortly.)
As for 1.14, well, “contributions welcome”, as they say. > On Jun 27, 2017, at 3:55 PM, Michael Alexeev <[email protected]> > wrote: > > 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 >>
