[jira] [Commented] (CALCITE-2450) RexSimplify: reorder predicates to a canonical form as a part of RexSimplify

["Julian Hyde (JIRA)" <ji...@apache.org>]

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

Julian Hyde commented on CALCITE-2450:
--------------------------------------

I am not keen on re-ordering predicates. Sometimes lists need to be ordered for safety (e.g. if we're going to generate code from "x is not null and x > 1" or "x > 0 and y / x < 6"). Sometimes lists need to be ordered by selectivity (most selective predicates first). This would break all that. Also, it would break quite a few tests.

I am also not in favor of adding a field to every RexNode.

However I do think we should consider adding a "final boolean simplified" field to a special sub-class of RexNode specifically for calls to AND. If "simplified", we would know that operands are deduplicated, flattened (i.e. none of them are ANDs). And -- this is up for debate -- they have been simplified and constant-reduced.

AND is so common that this will help significantly.

> RexSimplify: reorder predicates to a canonical form as a part of RexSimplify
> ----------------------------------------------------------------------------
>
>                 Key: CALCITE-2450
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2450
>             Project: Calcite
>          Issue Type: Sub-task
>          Components: core
>    Affects Versions: 1.17.0
>            Reporter: Vladimir Sitnikov
>            Assignee: Julian Hyde
>            Priority: Major
>
> Certain optimizations are easier to perform when input expressions are in a canonical form.
> For instance: more duplicates can be found in AND/OR lists, case branches, etc.
> Note: this reordering is supposed to happen in RexSimplify only. In other words, RexBuilder would still produce "non-canonical" expressions.
> It is expected that {{RexSimplify}} might alter the expression, so if it converts {{5=x}} to {{x=5}} it should be just fine.
> The suggested rules are to be discussed, yet the following might be fine:
> 1) For AND, OR, IN: put "simpler" nodes first. The weight of a node could be either {{.toString().length()}} or a number of child nodes or something like that.
> The motivation is to simplify logic that handles "duplicate" entries. It won't have to consider "both alternatives" all over the place.
> 2) For comparison with literals put literal as the second argument
> 3) For binary comparison, put node with less weight to the left



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)