You’re taking the right approach. It may seem like a fair amount of effort to create RelNode sub-classes and rule instances for each of the core relational operations, but all of those usually end up trivial. It’s not possible to extend an existing calling convention (although it’s an idea we should consider).
Regarding debugging plans. Have you tried turning on RelOptPlanner tracing[1]? Then you can see the equivalence sets and the cost estimates of the rel nodes. At a high level of tracing it prints the entire space every time a rule is applied, so can use a lot of disk space. Julian [1] https://calcite.apache.org/docs/howto.html#tracing <https://calcite.apache.org/docs/howto.html#tracing> > On Apr 16, 2017, at 7:22 PM, Christopher Wolff <[email protected]> wrote: > > Hi All, > > Over the past few months, I've been working off and on trying out Calcite > as a parser and planner front end to a database that I work on, VoltDB. > Overall I've been very impressed and have already been able to get plans > out of Calcite that are better than VoltDB's native planner in some cases. > > My approach thus far has been to implement derived classes that extend the > RelNode classes like Project, TableScan, Join, etc. These classes are all > part of the VoltDB calling convention, and I've defined a bunch of rules to > translate the logical operations into the VoltDB physical operations. Each > instance of VoltDBRel has a method that can be used to produce the > equivalent node in VoltDB's native plans once Calcite's planning is > complete. > > Is this the best approach? It's been working so far, but maybe there's a > better way, like extending another existing calling convention? > > One issue that we've been struggling with is getting some transparency into > why the planner chooses some plans over others. For example, I want to > apply JoinCommuteRule in order to swap the two children of a Join node. > The planner seems to consider applying this rule, but the final plan does > not have the children of the join swapped like I would have expected based > on the cost of the two subtrees. > > How can I get better insight into how the planner is making its choices? > > Again, I've thus far been very impressed and would welcome any tips the > folks on this mailing list could provide! > > Cheers, > Chris
