-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-24890] [SQL] Short circuiting the if condition when trueValue and falseValue are the same
#21848
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
[SPARK-24890] [SQL] Short circuiting the if condition when trueValue and falseValue are the same
#21848
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -390,6 +390,8 @@ object SimplifyConditionals extends Rule[LogicalPlan] with PredicateHelper { | |
| case If(TrueLiteral, trueValue, _) => trueValue | ||
| case If(FalseLiteral, _, falseValue) => falseValue | ||
| case If(Literal(null, _), _, falseValue) => falseValue | ||
| case If(cond, trueValue, falseValue) | ||
| if cond.deterministic && trueValue.semanticEquals(falseValue) => trueValue | ||
|
|
||
| case e @ CaseWhen(branches, elseValue) if branches.exists(x => falseOrNullLiteral(x._1)) => | ||
| // If there are branches that are always false, remove them. | ||
|
|
@@ -403,14 +405,14 @@ object SimplifyConditionals extends Rule[LogicalPlan] with PredicateHelper { | |
| e.copy(branches = newBranches) | ||
| } | ||
|
|
||
| case e @ CaseWhen(branches, _) if branches.headOption.map(_._1) == Some(TrueLiteral) => | ||
| case CaseWhen(branches, _) if branches.headOption.map(_._1).contains(TrueLiteral) => | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since we removed
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since it's not a bug fix, I guess it's unlikely someone will backport this :)
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes. In the community, it's not allowed for backport. I mean the others who want to have this.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Eh, in any event, wouldn't it be better to revert this change back if there's any actual advantage against a unrelated style change?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Normally, we avoid adding unneeded refactoring in such a PR. Please avoid it next time. Thanks! |
||
| // If the first branch is a true literal, remove the entire CaseWhen and use the value | ||
| // from that. Note that CaseWhen.branches should never be empty, and as a result the | ||
| // headOption (rather than head) added above is just an extra (and unnecessary) safeguard. | ||
| branches.head._2 | ||
|
|
||
| case CaseWhen(branches, _) if branches.exists(_._1 == TrueLiteral) => | ||
| // a branc with a TRue condition eliminates all following branches, | ||
| // a branch with a true condition eliminates all following branches, | ||
| // these branches can be pruned away | ||
| val (h, t) = branches.span(_._1 != TrueLiteral) | ||
| CaseWhen( h :+ t.head, None) | ||
|
|
@@ -651,6 +653,7 @@ object SimplifyCaseConversionExpressions extends Rule[LogicalPlan] { | |
| } | ||
| } | ||
|
|
||
|
|
||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: extra space line.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought we always have two new lines between two objects
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's okay to remove it back though assuming from
https://github.com/databricks/scala-style-guide#blank-lines-vertical-whitespace Looks either way is fine. |
||
| /** | ||
| * Combine nested [[Concat]] expressions. | ||
| */ | ||
|
|
||
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.
Looks like we'll still have this problem by skipping the evaluation of
cond..Lately, SPARK-33544 introduced another approach for that. I think that superseded SPARK-24913. I think we can switch it to use SPARK-33544 approach.
@dbtsai, can we try and follow up it with using
NoThrow?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.
cc @tgravescs too FYI