calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Nadeau <>
Subject Trait Propagation, requesting traits using RelOptRule.convert() & CALCITE-557
Date Sun, 01 Mar 2015 04:49:47 GMT
Hey Guys,

I was tired of a hack we use in Drill to make trait propagation work as it
blows out the plan space.  As such, I was building a simple example to
discuss here.  Of course, I ran across additional difficulties that I would
like to discuss.

I happen to build my initial example on an old copy of Calcite and got to
the point where I was illustrating the fact that we weren't doing trait
propagation.  However, rather than post that as an example, I wanted to
move to the latest Calcite so we could discuss in that context.

After updating all the code I've found a couple places where things have
changed and I'm not even sure how to implement my original pattern.  The
biggest issue that changed things looks like CALCITE-557 [1] since it
doesn't guarantee a converter is created to ensure a non-root trait
conversion at planning time.  I imagine I'm missing something in the new
paradigm but I'm not sure how to resolve given these changes.

The simple example is:

We have a logical plan that is Agg > Project > EnumTableAccess.

We then convert to a physical plan PhysAgg > PhysSort > PhysProj > PhysScan

The PhysAgg requires a collation trait since we'll imagine it is a
streaming aggregate.  To illustrate the trait propagation problem, I've
defined PhysScan to expose the required collation already.  The goal is to
get the PhysProj to propagate the collation trait so the PhysAgg doesn't
require insertion of a PhysSort.

On the old Optiq branch (~4 months back), I get the following plans using
AggregateRel(group=[{0}], cnt=[COUNT($1)])

PhysAgg(group=[{0}], cnt=[COUNT($1)])
  PhysSort(sort0=[$0], dir0=[ASC-nulls-first])
      PhysTable                      // dir0=[ASC-nulls-first]

On the new Branch using [3], I can't actually get this to plan because of
the removal in [1].

Is there a test case for trait propagation or simply a RelOptRule imposing
an additional trait that works after 557 was merged?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message