-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Restore lazy evaluation of fallible CASE #15390
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Alternatively, we could change |
Commit 0f4b8b1 introduced a new optimized evaluation mode for CASE expression with exactly one WHEN-THEN clause and ELSE clause being present. Apparently, the new mode did not take into account expensive or fallible expressions, as it unconditionally evaluated both branches. This is definitely incorrect for fallible expressions. For these, fallback to the original execution mode.
eb5d03b
to
fa4ff20
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @findepi
Given the code was generating incorrect answers but is now correct this looks good to me. I am running some benchmarks to see if there are any performance impacts
cc @aweltsch @2010YOUY01 who authored/helped with #13953
1 10 | ||
2 5 | ||
|
||
query II |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I verified that this errors on main:
> SELECT v, CASE WHEN v != 0 THEN 10/v ELSE 42 END FROM (VALUES (0), (1), (2)) t(v);
+---+-------------------------------------------------------------------+
| v | CASE WHEN t.v != Int64(0) THEN Int64(10) / t.v ELSE Int64(42) END |
+---+-------------------------------------------------------------------+
| 0 | 42 |
| 1 | 10 |
| 2 | 5 |
+---+-------------------------------------------------------------------+
3 row(s) fetched.
Elapsed 0.002 seconds.
> SELECT v, CASE WHEN v < 0 THEN 10/0 ELSE 1 END FROM (VALUES (1), (2)) t(v);
Arrow error: Divide by zero error
Here are my benchmark results. My conclusion is no discernable difference
|
* Restore lazy evaluation of fallible CASE Commit 0f4b8b1 introduced a new optimized evaluation mode for CASE expression with exactly one WHEN-THEN clause and ELSE clause being present. Apparently, the new mode did not take into account expensive or fallible expressions, as it unconditionally evaluated both branches. This is definitely incorrect for fallible expressions. For these, fallback to the original execution mode. * Workaround for running sqllogictests in RustRover
* Restore lazy evaluation of fallible CASE Commit 0f4b8b1 introduced a new optimized evaluation mode for CASE expression with exactly one WHEN-THEN clause and ELSE clause being present. Apparently, the new mode did not take into account expensive or fallible expressions, as it unconditionally evaluated both branches. This is definitely incorrect for fallible expressions. For these, fallback to the original execution mode. * Workaround for running sqllogictests in RustRover
Which issue does this PR close?
Rationale for this change
Commit 0f4b8b1 (#13953) introduced a new
optimized evaluation mode for CASE expression with exactly one WHEN-THEN
clause and ELSE clause being present. Apparently, the new mode did not
take into account expensive or fallible expressions, as it
unconditionally evaluated both branches. This is definitely incorrect
for fallible expressions. For these, fallback to the original execution
mode.
What changes are included in this PR?
fix so that CASE is lazy again
Are these changes tested?
slt
Are there any user-facing changes?
yes