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

Julian Hyde commented on CALCITE-1790:
--------------------------------------

I think that this would work, as long as we have (a) expression-optimization as 
we go (i.e. CALCITE-1794), and (b) a limit. There's a good change that the bugs 
in java generation will disappear, and if they don't, they can solved with a 
modest amount of work. But if that's more than your current time budget allows, 
I understand.

> Simplify CASE P1 THEN <boolean> P@ THEN <booleans> ...  ELSE TRUE/FALSE
> -----------------------------------------------------------------------
>
>                 Key: CALCITE-1790
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1790
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>            Reporter: Remus Rusanu
>            Assignee: Remus Rusanu
>            Priority: Minor
>
> In HIVE-14431 [~jcamachorodriguez] proposed a simplification for CASE when 
> all branches are not nullable boolean expression into an alternative 
> AND/OR/NOT based expression. This allows for more aggressive reductions and 
> split/push-down on the whole.  Meantime the simplifier code migrated to 
> Calcite so I'm reviving this here.
> The proposed simplification is:
> {code}
> CASE
> WHEN p1 THEN ex1
> WHEN p2 THEN ex2
> ...
> WHEN pn THEN exn
> ELSE TRUE/FALSE
> END
> {code}
> to be transformed into:
> {code}
> (p1 AND ex1)
> OR (not(p1) AND p2 AND x2)
> ...
> OR (not(p1) AND not(p2) ... AND not(pn-1) AND Pn AND exn)
> [OR (not(p1) AND not(p2) ... AND not(pn))]
> {code}
> The last OR is depending on the ELSE branch being TRUE/FALSE.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to