calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Wolff <>
Subject Using Calcite as front end to an RDBMS
Date Mon, 17 Apr 2017 02:22:43 GMT
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

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!


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