Jess> Is my test incorrect? This also fails:
The test looks like a correct one, however its correctness depends on
the implementation of runDuplicateSortCheck.
It turns out the implementation was wrong, so the top-level sort was
removed not by SortRemoveRule, but it was removed by a mere fact that
Is my test incorrect? This also fails:
runDuplicateSortCheck("select empid "
+ "from emps "
+ "order by name ",
"EnumerableSort(sort0=[$1], dir0=[ASC])\n"
+ " EnumerableProject(empid=[$0], name=[$2])
If the sort is trivial (i.e. its input is already sorted) then the outcome of
calling call.transformTo(…) will be to put the sort and its input into the same
subset. Thus the input could be used as a (cheaper) alternative.
If the sort is not trivial, the effect of the rule will be put the sort a
On Fri, Oct 14, 2016 at 5:16 PM, Julian Hyde wrote:
> Note the important expression:
>
> convert(sort.getInput(), traits)
>
> This creates a new relational expression (or returns an existing one) that
> is “input" sorted by the required fields. It doesn’t change “input”.
>
>
I dug into getOrCre
Note the important expression:
convert(sort.getInput(), traits)
This creates a new relational expression (or returns an existing one) that is
“input" sorted by the required fields. It doesn’t change “input”.
By the way, the Volcano paper talks about physical properties (what we call
traits)
