vlsi commented on a change in pull request #1818: [CALCITE-3809] RexSimplify
simplifies nondeterministic function incorrectly
URL: https://github.com/apache/calcite/pull/1818#discussion_r382803769
##########
File path: core/src/main/java/org/apache/calcite/rex/RexSimplify.java
##########
@@ -323,7 +323,7 @@ private RexNode simplifyComparison(RexCall e, RexUnknownAs
unknownAs) {
// Simplify "x <op> x"
final RexNode o0 = operands.get(0);
final RexNode o1 = operands.get(1);
- if (o0.equals(o1)) {
+ if (o0.equals(o1) && RexUtil.isDeterministic(o0)) {
Review comment:
Suppose the expression is always deterministic. It looks like "deep
isDeterministic" would fire too often, and it could ruin the performance of
RexSimplify for perfectly valid deterministic cases. That is not how the thing
should work.
If I were you, I would try to answer the following question:
1) Is it legitimate to simplify at all if non-deterministic functions are
known to exist in the tree.
For instance: `AND(rand(), true, true, rand())`
2) What do we want to do with #1 (e.g. keep unsimplified, or simplify
deterministic subexpressions)
3) Use a single pass to find non-deterministic expressions. A single pass is
enough to tell if the expression is fully deterministic or not. If it is, then
you don't need to check for non-deterministic expressions later.
I don't like adding non-trivial logic inside RexSimplify, because it is
really hard to tell if the resulting performance is linear or not.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
