You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Vladimir Sitnikov (JIRA)" <ji...@apache.org> on 2018/08/08 06:30:00 UTC
[jira] [Comment Edited] (CALCITE-2450) RexSimplify: reorder
predicates to a canonical form as a part of RexSimplify
[ https://issues.apache.org/jira/browse/CALCITE-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16572744#comment-16572744 ]
Vladimir Sitnikov edited comment on CALCITE-2450 at 8/8/18 6:29 AM:
--------------------------------------------------------------------
A slightly more sophisticated example would be
{noformat}
($0>0) AND (42/($0-1)>0) AND ($0<0)
// rex.toString gives AND(>($0, 0), >(/INT(42, -($0, 1)), 0), <($0, 0))
{noformat}
It is again is simplified to {{false}}, yet non-simplified expression would produce an error.
was (Author: vladimirsitnikov):
A slightly more sophisticated example would be
{noformat}
AND($0>0, 42/($0-1)>0, $0<0)
// rex.toString gives AND(>($0, 0), >(/INT(42, -($0, 1)), 0), <($0, 0))
{noformat}
It is again is simplified to {{false}}, yet non-simplified expression would produce an error.
> 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)