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
