[
https://issues.apache.org/jira/browse/CALCITE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesus Camacho Rodriguez resolved CALCITE-2179.
----------------------------------------------
Resolution: Fixed
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/aa25dcb . I will
tackle any possible additional work in follow-up issues.
> General improvements for materialized view rewriting rule
> ---------------------------------------------------------
>
> Key: CALCITE-2179
> URL: https://issues.apache.org/jira/browse/CALCITE-2179
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Jesus Camacho Rodriguez
> Assignee: Jesus Camacho Rodriguez
> Priority: Major
> Fix For: 1.16.0
>
>
> This issue is for extending {{AbstractMaterializedViewRule}} rule:
> - Support for rolling up date nodes. For instance, rewrite in the following
> case:
> {code}
> Materialization:
> select "empid", floor(cast('1997-01-20' as timestamp) to month), count(*) + 1
> as c, sum("empid") as s
> from "emps" group by "empid", floor(cast('1997-01-20' as timestamp) to month);
> Query:
> select floor(cast('1997-01-20' as timestamp) to year), sum("empid") as s
> from "emps" group by floor(cast('1997-01-20' as timestamp) to year);
> {code}
> - Add flag to enable/disable fast bail out for joins. By default it is true,
> and thus, we were only creating the rewriting in the minimal subtree of plan
> operators. For instance:
> {code}
> View: (A JOIN B) JOIN C
> Query: (((A JOIN B) JOIN D) JOIN C) JOIN E
> {code}
> We produce it at:
> {code}
> ((A JOIN B) JOIN D) JOIN C
> {code}
> But not at:
> {code}
> (((A JOIN B) JOIN D) JOIN C) JOIN E
> {code}
> This is important when the rule is used with the Volcano planner together
> with other rules, e.g. join reordering, as it prevents that the search space
> grows unnecessarily. However, if we use the rewriting rule in isolation, fast
> bail out can lead to missing rewriting opportunities (e.g. for bushy join
> trees).
> - Possibility to provide a HepProgram to optimize query branch in union
> rewritings. Note that when we produce a partial rewriting with a Union, the
> branch that will execute the (partial) query can be fully rewritten so we can
> add the compensation predicate. (We cannot do the same for views because the
> expression might not be computable if the needed subexpressions are not
> available in the view output). If we use Volcano with a determined set of
> rules, this might not be needed, hence providing this program is optional.
> - Multiple small fixes discovered while testing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
