You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by "Xurenhe (Jira)" <ji...@apache.org> on 2022/02/16 03:06:00 UTC

[jira] [Created] (CALCITE-5012) SubstitutionVisitor need a new rule to support remain top calc in mv.

Xurenhe created CALCITE-5012:
--------------------------------

             Summary: SubstitutionVisitor need a new rule to support remain top calc in mv.
                 Key: CALCITE-5012
                 URL: https://issues.apache.org/jira/browse/CALCITE-5012
             Project: Calcite
          Issue Type: Bug
            Reporter: Xurenhe


SubstitutionVisitor is a bottom-up to rewrite query's plan by mv.

Rewriting query successfully, when mv's plan has become a part of the query plan.

The current rules are as follows:
{code:java}
AggregateOnCalcToAggregateUnifyRule
AggregateToAggregateUnifyRule
CalcToCalcUnifyRule
IntersectOnCalcsToIntersectUnifyRule
IntersectToIntersectUnifyRule
JoinOnCalcsToJoinUnifyRule
JoinOnLeftCalcToJoinUnifyRule
JoinOnRightCalcToJoinUnifyRule
ScanToCalcUnifyRule
TrivialRule
UnionOnCalcsToUnionUnifyRule
UnionToUnionUnifyRule {code}
Their aims:
 * Predicate compensation by pulling-up

 * Project compensation by pulling-up
 * Aggregate roll-up

But, Rewriting query fails, when top rel of mv is calc.

And this rel just works for rearrangement of field's order or unused value filling.

Let me give some examples:

Case1

 
{code:java}
--query
SELECT deptno,
       sum(salary),
       sum(k)
FROM
  (SELECT deptno,
          salary,
          100 AS k
   FROM emps)
GROUP BY deptno;
--mv
SELECT deptno,
       sum(salary),
       sum(commission) + 1,
       sum(k)
FROM
  (SELECT deptno,
          salary,
          commission,
          100 AS k
   FROM emps)
GROUP BY deptno;
--query's plan
LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)], EXPR$2=[SUM($2)])
  LogicalCalc(expr#0..4=[{inputs}], expr#5=[100], deptno=[$t1], salary=[$t3], k=[$t5])
    LogicalTableScan(table=[[hr, emps]])
--mv's plan
LogicalCalc(expr#0..3=[{inputs}], expr#4=[1], expr#5=[+($t2, $t4)], proj#0..1=[{exprs}], EXPR$2=[$t5], EXPR$3=[$t3])
  LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)], agg#1=[SUM($2)], EXPR$3=[SUM($3)])
    LogicalCalc(expr#0..4=[{inputs}], expr#5=[100], deptno=[$t1], salary=[$t3], commission=[$t4], k=[$t5])
      LogicalTableScan(table=[[hr, emps]]) {code}
 

 

Case2

 
{code:java}
--query
SELECT deptno,
       salary
FROM emps
UNION
SELECT deptno,
       salary
FROM emps;
--mv
SELECT deptno,
       salary,
       'hello' AS k
FROM
  (SELECT deptno,
          salary
   FROM emps
   UNION SELECT deptno,
                salary
   FROM emps);
--query's plan
LogicalUnion(all=[false])
  LogicalCalc(expr#0..4=[{inputs}], deptno=[$t1], salary=[$t3])
    LogicalTableScan(table=[[hr, emps]])
  LogicalCalc(expr#0..4=[{inputs}], deptno=[$t1], salary=[$t3])
    LogicalTableScan(table=[[hr, emps]])
--mv's plan
LogicalCalc(expr#0..1=[{inputs}], expr#2=['hello'], proj#0..2=[{exprs}])
  LogicalUnion(all=[false])
    LogicalCalc(expr#0..4=[{inputs}], deptno=[$t1], salary=[$t3])
      LogicalTableScan(table=[[hr, emps]])
    LogicalCalc(expr#0..4=[{inputs}], deptno=[$t1], salary=[$t3])
      LogicalTableScan(table=[[hr, emps]]) {code}
 

 

We could define a new rule of HolderToCalcUnifyRule to solve these problems

Related issues:
 * CALCITE-5000: https://issues.apache.org/jira/browse/CALCITE-5000
 * CALCITE-4376: https://issues.apache.org/jira/browse/CALCITE-4376

Holder is top wrapped rel for query, link to `org.apache.calcite.rel.mutable.Holder`



--
This message was sent by Atlassian Jira
(v8.20.1#820001)