[
https://issues.apache.org/jira/browse/CALCITE-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16572892#comment-16572892
]
Vladimir Sitnikov edited comment on CALCITE-2450 at 8/8/18 8:48 AM:
--------------------------------------------------------------------
{quote}if we're going to generate code from "x is not null and x > 1"
{quote}
If {{x}} is nullable, it must be possible to generate code for {{x > 1}} no
matter if {{x is null}} or not.
In other words, code generator (it does not really matter if it is Janino
generator or Mongo query generator) MUST properly generate code for {{x > 1}}
and support {{null}} yielding {{null }}(or unknown if that matters).
Of course, the code generated for {{cast(x: nullable int)>1 and x is not null}}
might be slightly less efficient that the code for {{x is not null and x>1}},
however I do not see how ordering for {{x is not null and x>1}} is important.
Thus I think your first example is invalid or there's something unspoken in it.
Your second example on {{x > 0 and y / x < 6}} is different, and I think it is
important to know what should be the result of {{AND(42/0 > 0, false)}}.
I assume that {{x > 0 and y/x<6}} should be allowed to fail with "divide by
zero". If one needs to declare dependence, then {{case when x>0 then y/x<6
end}} should be used instead.
was (Author: vladimirsitnikov):
{quote} if we're going to generate code from "x is not null and x > 1" {quote}
If {{x}} is nullable, it must be possible to generate code for {{x > 1}} no
matter if {{x is null}} or not.
In other words, code generator (it does not really matter if it is Janino
generator or Mongo query generator) MUST properly generate code for {{x > 1}}
and support {{null}} producing {{null}}.
Of course, the code generated for {{cast(x: nullable int)>1 and x is not null}}
might be slightly less efficient that the code for {{x is not null and x>1}},
however I do not see how ordering for {{x is not null and x>1}} is important.
Thus I think your first example is invalid or there's something unspoken in it.
Your second example on {{x > 0 and y / x < 6}} is different, and I think it is
important to know what should be the result of {{AND(42/0 > 0, false)}}.
I assume that {{x > 0 and y/x<6}} should be allowed to fail with "divide by
zero". If one needs to declare dependence, then {{case when x>0 then y/x<6
end}} should be used instead.
> 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)
