Hi Haisheng, Thanks for raising awareness around this topic. I also think we should try to find a solution.
Initially, the Volcano planner was designed to be able to cover multiple models (and not only the relational). For non-relational models composite traits may be indispensable. I don't know if there are people in this list that are using the planner for other models but if there are it would be nice to hear from them. Focusing exclusively on the relational model, I think composite traits are useful. One use-case that comes to my mind is data replication. It perfectly makes sense to partition (distribute) your table on two (or more) columns to be able execute efficiently queries using special partition joins. A concrete use-case is RDF data where many distributed systems store the triples table partitioned by subject and object. I guess such use-cases could possibly be modelled in other ways but composite traits is what comes naturally to my mind. Regarding multi-sorted tables it is not that rare if you import sorted data into a table with an auto-increment primary key for example. I think all the trait-related issues can be solved if we prioritize them correctly. Apart from Vladimir and Hongze, who already spend quite some time on these, the rest of us should also jump in and try to help. Best, Stamatis On Sun, Apr 7, 2019 at 9:48 AM Haisheng Yuan <[email protected]> wrote: > Hi, > > I found there are some RelCompositeTrait related issues: > https://issues.apache.org/jira/browse/CALCITE-2010 > https://issues.apache.org/jira/browse/CALCITE-2593 > https://issues.apache.org/jira/browse/CALCITE-2764 > > Multi-sorted table are rare in pratice, mutil-distributed table doesn't > exist either. Values node with several tuples is not worth optimization, > with many tuples is not worth optimization either, because the time it > takes optimizer to figure out the ordering may be longer than just sort it > in runtime. > > In issue https://issues.apache.org/jira/browse/CALCITE-1990, > Leo extended RelDistribution to inherit RelMultipleTrait, just like > RelCollation does, to solve his problem in the example. But I don't think > this is an appropriate way to represent the equivalence classes (in > PostgreSQL's term). > > So why did we introduce RelCompisteTrait and RelMultipleTrait in the > beginning? Seems like it gives us more pain than gain. > > Thanks ~ > Haisheng Yuan >
