[jira] [Created] (CALCITE-2179) General improvements for materialized view rewriting rule

["Jesus Camacho Rodriguez (JIRA)" <ji...@apache.org>]

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)