[
https://issues.apache.org/jira/browse/CALCITE-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975646#comment-15975646
]
MinJi Kim commented on CALCITE-1753:
------------------------------------
It looks like I spoke too soon. I tried enabling ProjectFilterTransposeRule to
use ExprCondition.TRUE, but that seem to cause a lot of issues. For one,
pushing more general expressions down results in these weird plans where the
filter isn't evaluating anything and pushes it to the project below to evaluate
the filter condition and the filter just checks the condition to be true/false.
I didn't think it was buying much, since pushing down the input reference
reduces the number of columns selected and is useful, but pushing the filter
condition evaluation didn't seem to be as useful in my mind. I think for now,
I would be happy to keep it as it is. Do you agree?
{code}
LogicalFilter(condition=[$3])
LogicalProject(ENAME=[$1], SAL=[$5], DEPTNO=[$7], >=[>($5, 5000)])
{code}
> ProjectJoinTransposeRule with preserveExprCondition pushes projects below
> outer-joins
> -------------------------------------------------------------------------------------
>
> Key: CALCITE-1753
> URL: https://issues.apache.org/jira/browse/CALCITE-1753
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: MinJi Kim
> Assignee: Julian Hyde
> Fix For: 1.13.0
>
>
> I am pushing case statements past joins using ProjectJoinTransposeRule. For
> inner joins, the current behavior seems fine, but outer joins can lead to
> weird behavior, where the project is below the join and nulls can cause
> issues.
> {code}
> select
> count(*), case when t3.a3 is not null then t3.a3 else 100 end
> from
> t1 left outer join t3 on t1.c1 = t3.c3
> group by
> case when t3.a3 is not null then t3.a3 else 100 end
> order by
> case when t3.a3 is not null then t3.a3 else 100 end
> {code}
> Currently, ProjectJoinTransposeRule will push the case statement below the
> join as below. But, this case statement shouldn't be pushed. The query
> shouldn't return null but instead as 100 for any "unmatched" join condition
> since it is a left outer join with a case statement. But, the current plan
> would not prevent that.
>
> {code}
> LogicalProject with case statement
> LogicalJoin
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
> {code}
> LogicalProject
> LogicalJoin
> LogicalProject with case statement
> LogicalTableScan(table=[t1])
> LogicalTableScan(table=[t3])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
