[
https://issues.apache.org/jira/browse/CALCITE-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16018514#comment-16018514
]
Julian Hyde commented on CALCITE-1790:
--------------------------------------
I think we need a limit, and it needs to be part of this commit. Otherwise it
is not a "simplification" if sometimes it can produce an expression many times
larger than the original.
Can you include a test which a case statement of parameterized size -- say 100
-- and make sure that it gets through simplification and execution in a
reasonable time.
RexUtil.CnfHelper has a maxNodeCount field, added in CALCITE-1290, so there is
a precedent for this.
I wonder whether the the default setting (applied automatically by RelBuilder)
should apply the simplification only if there is an improvement, or perhaps a
minor degradation.
A few {{RelOptRulesTest}} instances seem to have gotten worse:
{noformat}
@@ -5631,7 +5631,7 @@ LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
<![CDATA[
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[1])
- LogicalFilter(condition=[=($7, 10)])
+ LogicalFilter(condition=[AND(<>($7, 20), =($7, 10))])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
]]>
</Resource>
@@ -5656,7 +5656,7 @@ LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
<![CDATA[
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[1])
- LogicalFilter(condition=[=($7, 10)])
+ LogicalFilter(condition=[OR(AND(<>($7, 20), =($7, 10)), AND(<>($7, 20),
null))])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
]]>
</Resource>
@@ -5683,7 +5683,7 @@ LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
<![CDATA[
LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
LogicalProject($f0=[1])
- LogicalFilter(condition=[OR(=($7, 30), =($7, 10))])
+ LogicalFilter(condition=[OR(=($7, 30), AND(<>($7, 20), =($7, 10)))])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
]]>
</Resource>
{noformat}
> 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)
