[
https://issues.apache.org/jira/browse/CALCITE-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15892942#comment-15892942
]
Kevin Risden commented on CALCITE-1668:
---------------------------------------
>From [~julianhyde]:
We have support for this in planner rules -- I’m pretty sure that
ReduceExpressionsRule.FILTER_INSTANCE will convert ‘where 1 = 0’ to ‘where
false’, then PruneEmptyRules.FILTER_INSTANCE will make the Filter disappear
altogether — but arguably it could happen in RexUtil.simplify also.
The purpose of RexUtil.simplify is to simplify (only) patterns that are
commonly occurring, easy to recognize, and will produce a quick win in terms of
the size of the RelNode/RexNode tree. I don’t know yet whether this passes that
threshold. Can you log a JIRA case for this and we can discuss further?
By the way, CALCITE-1638 is related. It changed the result of a test that was
doing ‘where 1 = 1’.
> RexUtil.simplify handle literal comparison simplification
> ---------------------------------------------------------
>
> Key: CALCITE-1668
> URL: https://issues.apache.org/jira/browse/CALCITE-1668
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Kevin Risden
> Assignee: Julian Hyde
> Priority: Minor
>
> From the calcite-dev mailing list:
> Calcite doesn't seem to optimize away the literal comparison literal case
> with RexUtil.simplify. In my understanding any literal comparison literal
> results in a simple TRUE/FALSE result.
> I'm not sure this is valid in the general case, but I put together a simple
> example of doing this on the RexUtil simplifyCall.
> https://github.com/apache/calcite/pull/376
> Reference:
> http://mail-archives.apache.org/mod_mbox/calcite-dev/201702.mbox/%3CCAJU9nmidm%3DiXNG46YhSthXaBG0CGfmtPraxU9MxEOxnCTTLa_A%40mail.gmail.com%3E
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
