[
https://issues.apache.org/jira/browse/CALCITE-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565650#comment-15565650
]
Michael Mior commented on CALCITE-1389:
---------------------------------------
Definitely far from production quality IMO, but I think interesting enough to
be included. I'll have to think over what would happen in each of the scenarios
you presented above, but it's definitely not very robust at this point. Some
more test cases clarifying the current behaviour are definitely in order.
That said, I've tried to make the rule fairly restrictive so it won't try to
rewrite cases that aren't correctly handled. For example, I check that all the
joins are inner joins. My target for this is conjunctive queries with equality
predicates and simple field references in the SELECT clause.
bq. Or if the the MV doesn't use any table twice, but the MV does?
I assume one of the references to MV above should be query?
I haven't thought specifically about the complexity of this approach, but I
would expect poor performance with a large number of MVs. The paper gives some
ideas on how to build index structures to optimize this. On a related note, if
you have any suggestions on where an appropriate place in the code would be to
construct such indexes and what object should own the index data, that would be
helpful.
As for where this fits into planning, I think this could still work as part of
Volcano. Using MVs when possible is not always the best choice. It also enables
cost-based selection of multiple MVs when that's an option.
Thanks for the style suggestions. I fixed those issues.
> 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)
