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 2015/07/22 00:05:04 UTC

[jira] [Commented] (CALCITE-808) Optimize ProjectMergeRule

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

Julian Hyde commented on CALCITE-808:
-------------------------------------

Note that if you want the old behavior, rather than using ProjectMergeRule.INSTANCE, you should create your own instance with force = false: {code}new ProjectMergeRule(false, RelFactories.DEFAULT_PROJECT_FACTORY){code}

> Optimize ProjectMergeRule
> -------------------------
>
>                 Key: CALCITE-808
>                 URL: https://issues.apache.org/jira/browse/CALCITE-808
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Julian Hyde
>            Assignee: Julian Hyde
>             Fix For: 1.4.0-incubating
>
>
> Optimize ProjectMergeRule to use RelOptUtil.pushPastProject rather than creating two RexPrograms and merging them. The current approach generates a lot of gc pressure.
> One side effect will be to remove some identity projects. ProjectMergeRule currently refuses to reduce identity projects if the fields have different names.
> For instance suppose you have a table Dept (deptno, name) and the algebra
> {noformat}
>   2: Project($1 as X, $0 as Y)
>     1: Project($1, $0)
>       0: Scan(Dept)
> {noformat}
> Observe that if you combine projects #1 and #2 you end up with
> {noformat}
>   3: Project($0 as X, $1 as Y)
>     0: Scan(Dept)
> {noformat}
> Although the new project (#3) is an identity, it renames the fields. ProjectMergeRule will return the new project (#3), but it could return Scan(Dept) (#0). I think the latter is better, so that will be the new behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)