[ https://issues.apache.org/jira/browse/CALCITE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087322#comment-17087322 ]
Vineet Garg commented on CALCITE-3928: -------------------------------------- [~jinxing6...@126.com] Can you provide the actual query or test case? We might be missing a case for rewriting but I am not sure if I understand this fully. > 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)