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) and enforcers. An enforcer is a relational operator that doesn’t change 
the logical content of the data, just changes its physical properties.

Every physical property has a corresponding enforcer: Sort is the enforcer of 
the Collation trait; Shuffle is the enforcer of the Distribution trait; Convert 
is the enforcer of the CallingConvention trait.

The short piece of code you quoted may seem almost trivial, but it is stating 
something profound: the relationship between Sort and Collation.

The trick, of course, is to find a way of achieving a sort order without using 
a sort (e.g. finding a copy of the table that contains the columns you want and 
is sorted in the order you want, i.e. an index). The whole reason we have the 
concept of physical properties is to make that kind of optimization (sometimes) 


> On Oct 14, 2016, at 2:33 PM, Jess Balint <> wrote:
> Just doing a bit of code reading here. Looking at the SortRemoveRule
> implementation:
>    // Express the "sortedness" requirement in terms of a collation trait
> and
>    // we can get rid of the sort. This allows us to use rels that just
> happen
>    // to be sorted but get the same effect.
>    final RelCollation collation = sort.getCollation();
>    assert collation == sort.getTraitSet()
>        .getTrait(RelCollationTraitDef.INSTANCE);
>    final RelTraitSet traits =
> sort.getInput().getTraitSet().replace(collation);
>    call.transformTo(convert(sort.getInput(), traits));
> I don't understand how this is correct without checking that the input
> collation is the same as the collation requested by the sort. It looks to
> me like it just replaces the input's collation with that of the sort. Any
> thoughts?
> Thanks.
> Jess

Reply via email to