[ 
https://issues.apache.org/jira/browse/CALCITE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375126#comment-16375126
 ] 

Jesus Camacho Rodriguez commented on CALCITE-2179:
--------------------------------------------------

Addendum in http://git-wip-us.apache.org/repos/asf/calcite/commit/353a8be to 
create references based on input node type during the rewriting (may prevent 
difference in nullability 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)

Reply via email to