[
https://issues.apache.org/jira/browse/CALCITE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15563739#comment-15563739
]
Julian Hyde commented on CALCITE-1389:
--------------------------------------
I reviewed your change. It looks fine, but a few comments:
* I don't get a sense that this is very robust. It may be robust, but to be
convinced, I'd need to see a lot more tests covering more of the potential
patterns.
* I can't figure out how it would fit into multi-phase planning. It seems to be
a Hep step. So, would it happen early in the planning process, before Volcano?
* Can it handle multiple MVs? What if more than one matches?
* If you have an MV on {{A join B}}, can it match a query {{A join B join C}};
can it match a query {{B join C}}?
* What if there are intervening GROUP BYs between the items in the join tree
(or SELECT DISTINCTs or semi-joins).
* What if the MV uses the same table twice, by different join paths? Or if the
the MV doesn't use any table twice, but the MV does?
* What are the performance characteristics if the number of MVs grows large?
In short, I can't tell how far this is along the road to production quality. It
doesn't need to be production quality (we can flag it as 'experimental') but we
do need to know what cases it can handle, what the deficiencies are, and which
of those deficiencies could be addressed by future work.
Code style:
* If you need to wrap arguments, e.g.
https://github.com/apache/calcite/pull/284/files#diff-937b1dde0b0e60b098796a4a10d4a2e6R115,
don't align with the '(', instead indent 4.
* In method javadoc, use active "Produces ..." rather than imperative "Produce
..."
> Add rule to perform rewriting of queries using materialized views with joins
> ----------------------------------------------------------------------------
>
> Key: CALCITE-1389
> URL: https://issues.apache.org/jira/browse/CALCITE-1389
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Michael Mior
> Assignee: Michael Mior
> Fix For: 1.11.0
>
>
> I've been looking into implementing the approach from the following paper.
> It's very nicely written and easy to follow. It also doesn't require trying
> different join permutations. I'm starting with several additional
> restrictions (only equijoins, no aggregations, etc.)
> ftp://ftp.cse.buffalo.edu/users/azhang/disc/SIGMOD/pdf-files/331/202-optimizing.pdf
> Thanks to [~jcamachorodriguez] for his help in sorting out some issues with
> the rule so far.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
