I've been playing with this some more. The rule appears to perform the
correct substitution. That is, I change a LogicalProject on top of a Join
of two TableScans into a LogicalProject on top of a TableScan of the
materialized view. However, the new RelNode ends up in a different subset
within the
Here's the code I have so far
https://gist.github.com/michaelmior/b2724b0c9fcd1f756f2e8379c99de66c
I just add this rule along with MaterializedViewFilterScanRule in
CalcitePrepareImpl. Note that there are probably some necessary checks
missing and the code is a bit messy, but I'm hoping to get so
I would be interested in taking a look at your work so far, if you can
throw it on a github gist or some other host that would allow for
commenting that would probably be best.
Jason Altekruse
Software Engineer at Dremio
Apache Drill Committer
On Wed, Jun 15, 2016 at 12:43 PM, Michael Mior wrote
Any further ideas of what might be going on or suggestions on how to debug
this? I can put together a sample of the code I have so far if anyone is
willing to spend a bit of time looking through it (~300 LOC). Thanks!
--
Michael Mior
mm...@uwaterloo.ca
2016-06-13 14:49 GMT-04:00 Michael Mior :
>
Julian,
I understand that MultiJoin cannot be implemented directly. I'm only using
it to collect information on multiple joins into a single node since it
makes further steps of the algorithm much easier. Ultimate the rewrite rule
is attempting to match a LogicalProject on top of a LogicalJoin of
Using MultiJoin is a good idea. But remember that it was designed with only
one, very specific purpose: to gather joins to be optimized by a greedy
algorithm.
MultiJoin cannot be implemented directly. In fact the only rule that can digest
it and convert it into regular Join nodes is LoptOptimiz
I'm close to getting something working for the case of two tables. I don't
think it should be too challenging to extend to multiple tables. The gist
of the approach is to match a Join over two TableScans and then use
JoinToMultiJoin rule to get a MultiJoin instance. This is useful because
it's much
Sorry, I missed Lattices as I didn't know about Lattices without
aggregations. Btw there is this rule where we try to replace star table
scan by Tiles of Lattices with filters:
https://github.com/qubole/quark/blob/master/optimizer/src/main/java/com/qubole/quark/planner/FilterAggStarRule.java
I thou
Yes, I think you could make Lattices work without aggregation, as long as you
keep the key assumption, which is that dropping joined tables does not change
the number of rows (so, primary key and foreign key integrity, relationships
are all many-to-one from the root (fact) table, and you have to
Thanks for the pointer. Any chance there's a good example somewhere using
lattices that would help me get something working? Also, is it possible to
have lattices with no aggregation? Unfortunately either way it doesn't
completely suit my use case since I'm going to have to do rewriting on
joins as
Short answer: yes, if you use lattices.
Remember, Calcite has two mechanisms for matching materialized views: the
"general purpose" mechanism, and lattices.
Using general purpose mechanism you can declare a materialized view based on
any query, but there needs to be a unification rule to rewrit
AFAIK it doesn't. Not sure if some work has been done towards it.
Sent from my iPhone
> On 06-Jun-2016, at 7:08 AM, Michael Mior wrote:
>
> Am I correct in understanding that Calcite doesn't currently rewrite
> queries to use materialized views if the query which defines the view
> includes a jo
Am I correct in understanding that Calcite doesn't currently rewrite
queries to use materialized views if the query which defines the view
includes a join? If this is the case, has there been any work towards
making this happen?
--
Michael Mior
michael.m...@gmail.com
13 matches
Mail list logo
