[
https://issues.apache.org/jira/browse/CALCITE-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573902#comment-16573902
]
Vladimir Sitnikov commented on CALCITE-2450:
--------------------------------------------
{quote}Re first example: It is valid. I was thinking about generating janino
code that uses unboxing.{quote}
I am sure you meant that.
Let me explain: {{x is not null and x>0}} means {{x}} is NULLABLE in both
places, isn't it?
That is janino code generator translates gt(input("x"), literal(0)), and it
knows that "x" is nullable.
Of course it should use proper boxed-unboxed type to store {{x}}.
I am perfectly aware that there were multiple bugs of that kind (when
RexToLixTranslator tried to put null into {{boolean}} field or the other way
around), however I am perfectly sure the translator does NOT depend on the
order of elements in AND block.
It is full of {{RexImpTable.NullAs}} to optimize for "not-null" cases, however
those are just optimizations, and it does not change semantics of the
expression.
{code:java} Expression translate(RexNode expr) {
final RexImpTable.NullAs nullAs =
RexImpTable.NullAs.of(isNullable(expr));
return translate(expr, nullAs);
}
{code}
{quote}Re second example. Yes, good point. We have been bending SQL semantics
and assuming that AND cannot be re-ordered. It is better to assume that AND can
be re-ordered and CASE cannot be re-ordered. That should become our policy. I
still start an email thread to discuss.{quote}
Perfect. I'm sure we need to document somewhere the policy re the optimizations.
{quote} It is better to assume that AND can be re-ordered and CASE cannot be
re-ordered{quote}
+1 here.
There are relevant questions:
1) What is the expected argument evaluation order (depth-first, bread-first,
non-defined)? I would like to specify "not specified in general"
2) Is expression {{NOT(x < y)}} the same as {{x >= y}}? For numerics both
expressions match, however if {{x}} and {{y}} are custom-defined data types,
then the semantics of {{<}} and {{>=}} might differ very much. AFAIK PostgreSQL
enables to re-define the semantics of <, >= and so on (see
https://www.postgresql.org/docs/10/static/indexes-opclass.html), so technically
speaking the replacement of {{NOT(x<y)}} to {{x>=y}} does not work for every
{{op class}}
3) Is expression {{a + b}} the same as {{b + a}}? Apparently it would produce
different results for floating point.
> 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)
