Is there a JIRA case for this? It sounds similar to what Atri is working on.
Also, I think I ran into it while I was extending Atri’s partial fix for https://issues.apache.org/jira/browse/CALCITE-873 <https://issues.apache.org/jira/browse/CALCITE-873> in https://github.com/julianhyde/calcite/tree/873-weaken-sort <https://github.com/julianhyde/calcite/tree/873-weaken-sort> (which I never finished, possibly because I ran into deeper bugs). Julian > On Jun 20, 2017, at 8:42 PM, Michael Mior <[email protected]> wrote: > > The LogicalSort in this case can be pushed passed the LogicalJoin (e.g. via > SortJoinTransposeRule) so it's child would still be the TableScan and the > rule would still match. > > -- > Michael Mior > [email protected] > > 2017-06-20 20:47 GMT-04:00 Michael Alexeev <[email protected]>: > >> Michael, >> >> Yes, this would work in this case but what about a bit more complicated >> example with join >> >> SELECT R1.I FROM R1 JOIN R2 on R1.I = R2.II ORDER BY R1.I; >> >> Here, the order will still be guaranteed by the R1 index and the sort can >> be eliminated but there will be a LogicalJoin in between the LogicalSort >> and >> the TableScan that in general can not be pushed thought the LogicalSort, >> right? >> >> Mike >> >> On Tue, Jun 20, 2017 at 1:14 PM, Michael Mior <[email protected]> wrote: >> >>> You may find it easier to just have your rule explicitly match a >>> LogicalSort on top of a TableScan. Then you can just simply check the >>> indices of the fields. Existing rules should help reorder other operators >>> to produce a tree of this form if needed. >>> >>> -- >>> Michael Mior >>> [email protected] >>> >>> 2017-06-19 16:39 GMT-04:00 Michael Alexeev <[email protected]>: >>> >>>> Hi All, >>>> >>>> I am trying to write a rule to eliminate a potentially redundant >>>> LogicalSort node. >>>> >>>> Consider >>>> >>>> SELECT I FROM R1 ORDER BY I; >>>> >>>> The initial tree is >>>> LogicalSort(sort0=[$0], dir0=[DESC]) >>>> LogicalProject(I=[$0]) >>>> MyTableScan(table=[[R1]], expr#0..5=[{inputs}], >> proj#0..5=[{exprs}]) >>>> >>>> and after all the transformations are applied it becomes >>>> >>>> LogicalSort(sort0=[$0], dir0=[DESC]) >>>> MyTableScan(table=[[R1]], expr#0..5=[{inputs}], I=[$t0]) >>>> >>>> The LogicalProject is merged with the MyTableScan which retains all the >>>> original project expressions inside a local RexProgram instance >>>> >>>> If MyTableScan already produces rows in an order that matches the ORDER >>> BY >>>> (for example, an underlying table could have an index that guarantees >> the >>>> ordering if the scan uses that index to retrieve the rows) then >>> LogicalSort >>>> is not required and could be eliminated. >>>> My approach is to write a transformation rule to match the LogicalSort >>> node >>>> and its onMatch method would use a custom RelShuttleImpl class to >> visit a >>>> child TableScan. The shuttle can compare the collation fields list with >>> the >>>> list of the project expressions to decide whether the sort order >>>> is compatible with the index order and the sort can be eliminated. >>>> >>>> Does this approach sound reasonable? >>>> >>>> The problem is that I can't figure out how to establish a >> correspondence >>>> between the sort's collation fields and the scan's columns. Is there a >>>> proper way? If not, what would be a recommended approach? >>>> >>>> >>>> Any help is greatly appreciated, >>>> Mike >>>> >>> >>
