[jira] [Updated] (CALCITE-3928) Canonicalization doesn't do field trimming before materialized view matching
[
https://issues.apache.org/jira/browse/CALCITE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jin Xing updated CALCITE-3928:
--
Description:
If we have query and materialized view as below:
{code:java}
query:
LogicalAggregate(group=[{4}], agg#0=[COUNT($3)])
LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], SAL=[$5], DEPTNO=[$7])
LogicalTableScan(table=[[scott, EMP]])
mv logic:
LogicalAggregate(group=[{1}], agg#0=[COUNT($0)])
LogicalProject(SAL=[$5], DEPTNO=[$7])
LogicalTableScan(table=[[scott, EMP]])
{code}
The semantics of query and mv logic are the same. Materialized view matching
failed, because field trimming is not done when canonicalizing the plans.
Currently Calcite does field trimming when convert sql to rel. But my
company's internal system does materialization detection – – generates &
transforms & stores the RelNode.
Shall we add the field trimming when canonicalizing materialized view logic?
was:
If we have query and materialized view as below:
{code:java}
query:
LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $1)])
LogicalProject(a=$0, b=[bfunc($1)])
LogicalTableScan(table=[[default, user_table]])
mv:
LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $2)])
LogicalProject(a=$0, b=[bfunc($1)], c=[bfunc($1)])
LogicalTableScan(table=[[default, user_table]])
{code}
The semantics of query and mv logic are the same. Materialized view matching
failed, because field trimming is not done when canonicalizing the plans.
Currently Calcite does field trimming when convert sql to rel. But my
company's internal system does materialization detection – – generates &
transforms & stores the RelNode.
Shall we add the field trimming when canonicalizing materialized view logic?
> Canonicalization doesn't do field trimming before materialized view matching
>
>
> Key: CALCITE-3928
> URL: https://issues.apache.org/jira/browse/CALCITE-3928
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Priority: Major
> Labels: materializedviews
>
> If we have query and materialized view as below:
> {code:java}
> query:
> LogicalAggregate(group=[{4}], agg#0=[COUNT($3)])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], SAL=[$5], DEPTNO=[$7])
> LogicalTableScan(table=[[scott, EMP]])
> mv logic:
> LogicalAggregate(group=[{1}], agg#0=[COUNT($0)])
> LogicalProject(SAL=[$5], DEPTNO=[$7])
> LogicalTableScan(table=[[scott, EMP]])
> {code}
> The semantics of query and mv logic are the same. Materialized view matching
> failed, because field trimming is not done when canonicalizing the plans.
> Currently Calcite does field trimming when convert sql to rel. But my
> company's internal system does materialization detection – – generates &
> transforms & stores the RelNode.
> Shall we add the field trimming when canonicalizing materialized view logic?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3928) Canonicalization doesn't do field trimming before materialized view matching
[
https://issues.apache.org/jira/browse/CALCITE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vineet Garg updated CALCITE-3928:
-
Labels: materializedviews (was: )
> Canonicalization doesn't do field trimming before materialized view matching
>
>
> Key: CALCITE-3928
> URL: https://issues.apache.org/jira/browse/CALCITE-3928
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Priority: Major
> Labels: materializedviews
>
> If we have query and materialized view as below:
> {code:java}
> query:
> LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $1)])
> LogicalProject(a=$0, b=[bfunc($1)])
> LogicalTableScan(table=[[default, user_table]])
> mv:
> LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $2)])
> LogicalProject(a=$0, b=[bfunc($1)], c=[bfunc($1)])
> LogicalTableScan(table=[[default, user_table]])
> {code}
> The semantics of query and mv logic are the same. Materialized view matching
> failed, because field trimming is not done when canonicalizing the plans.
> Currently Calcite does field trimming when convert sql to rel. But my
> company's internal system does materialization detection – – generates &
> transforms & stores the RelNode.
> Shall we add the field trimming when canonicalizing materialized view logic?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3928) Canonicalization doesn't do field trimming before materialized view matching
[
https://issues.apache.org/jira/browse/CALCITE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jin Xing updated CALCITE-3928:
--
Summary: Canonicalization doesn't do field trimming before materialized
view matching (was: Canonicalization doesn't do field trimming before
materialized matching)
> Canonicalization doesn't do field trimming before materialized view matching
>
>
> Key: CALCITE-3928
> URL: https://issues.apache.org/jira/browse/CALCITE-3928
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Priority: Major
>
> If we have query and materialized view as below:
> {code:java}
> query:
> LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $1)])
> LogicalProject(a=$0, b=[bfunc($1)])
> LogicalTableScan(table=[[default, user_table]])
> mv:
> LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $2)])
> LogicalProject(a=$0, b=[bfunc($1)], c=[bfunc($1)])
> LogicalTableScan(table=[[default, user_table]])
> {code}
> The semantics of query and mv logic are the same. Materialized view matching
> failed, because field trimming is not done when canonicalizing the plans.
> Currently Calcite does field trimming when convert sql to rel. But my
> company's internal system does materialization detection – – generates &
> transforms & stores the RelNode.
> Shall we add the field trimming when canonicalizing materialized view logic?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
