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

[jira] [Updated] (CALCITE-3928) Canonicalization doesn't do field trimming before materialized 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=[{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 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)