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

[jira] [Commented] (CALCITE-4037) AggregateProjectMergeRule doesn't always respect column aliases

    [ https://issues.apache.org/jira/browse/CALCITE-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169879#comment-17169879 ] 

Julian Hyde commented on CALCITE-4037:
--------------------------------------

I am skeptical about this bug. Preserving the field names of the Aggregate seems to be the correct behavior. (As a policy, rules try to preserve field names, unless doing so would make the result more complex or less efficient.)

SQL-to-Rel seems to have produced some funky field names in this example, but even so, the rule isn’t the place to fix that.

> AggregateProjectMergeRule doesn't always respect column aliases
> ---------------------------------------------------------------
>
>                 Key: CALCITE-4037
>                 URL: https://issues.apache.org/jira/browse/CALCITE-4037
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>            Reporter: Sylvain Crozon
>            Priority: Major
>              Labels: pull-request-available
>         Attachments: fix-AggregateProjectMergeRule.patch
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> When columns aggregated over are given an alias, but not aggregated values, the alias is lost: 
> {code:java}
> select deptno as x, sum(sal)
> from emp
> group by deptno
> {code}
> has the following plan
> {code:java}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($1)])
>   LogicalProject(X=[$7], SAL=[$5])
>     LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
>  which becomes  
> {code:java}
> LogicalAggregate(group=[{7}], EXPR$1=[SUM($5)])
>   LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
>  
> after the AggregateProjectMergeRule
>  
> I attempted a fix by comparing the row type's field names of the project node with its input, and skip merging with the agg node if they don't match. That works for the use case above, however that breaks quite a few unit tests. Some of them, I believe, should be updated like 
> testAggregateMerge1, the alias in the SQL queries are lost in the final plan. But for other use cases, mostly when there's a join, the simple column name comparison is not enough. 
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)