Jesus Camacho Rodriguez created CALCITE-2179:
------------------------------------------------

             Summary: 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
             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