If you want a demo of the lattice optimizer in action, edit
core/src/test/resources/hsqldb-foodmart-lattice-model.json and change the line
algorithm: false,
to
algorithm: true,
Then connect to that model from sqlline:
$ sqlline
sqlline> !connect
jdbc:calcite:model=core/src/test/resources/hsqldb-foodmart-lattice-model.json
sa sa
sqlline> !tables
It takes a while to connect because it needs to load the embedded hsqldb data
set and run the optimization algorithm. You will see in the output from
‘!tables’ that there are about 20 tables named “m{16, 17, 32}” or similar.
These are the summary tables chosen by the algorithm and populated as in-memory
tables. Run some queries against the foodmart schema and you will see those
tables being used.
The algorithm can of course create tables in external databases, defer
population, use tables you have designed manually, and so forth.
Julian
as the model file. When calcite connects, it runs the optimizer and chooses
> On Nov 25, 2015, at 5:49 PM, Sarnath <[email protected]> wrote:
>
> Hi Julian,
> Thanks for the education. This makes lot of sense. I was under the
> impression that I will have to implement the summary table optimizer
> myself. But from your answer it looks like Calcite already provided a
> mechanism for this. This is really great! I will check out the docs further
> to see how to implement and register summary tables.
> Calcite is one of the most interesting project that I am recommending my
> colleagues to follow through. Even yesterday, we were recommending to check
> the Calcite-mongo connector for one of our customer's research prototype.
> Thanks,
> Best,
> Sarnath
