[SPARK-35886][SQL] CodeGenerator.getLocalInputVariableValues should handle case that expression match SubExprEliminationState but not VariableValue#33082
Conversation
…andle matched subQuery but not VariableValue
|
Kubernetes integration test starting |
|
Kubernetes integration test status success |
|
Test build #140318 has finished for PR 33082 at commit
|
|
Kubernetes integration test starting |
|
Kubernetes integration test status success |
|
Test build #140333 has finished for PR 33082 at commit
|
|
Also cc @viirya |
| } | ||
|
|
||
| test("SPARK-35886: CodeGenerator.getLocalInputVariableValues should handle " + | ||
| "matched subQuery but not VariableValue") { |
There was a problem hiding this comment.
you mean but not ONLY VariableValue?
| collectLocalVariable(value, e) | ||
| collectLocalVariable(isNull, e) |
There was a problem hiding this comment.
Oh, some SubExprEliminationState contains not VariableValue but still some statements that includes other expressions?
There was a problem hiding this comment.
Oh, some
SubExprEliminationStatecontains notVariableValuebut still some statements that includes other expressions?
Yes, the expression contains input var may match SubExprEliminationState and just skiped.
There was a problem hiding this comment.
Hmm, after second look, it looks not root cause. A subexpr should be evaluated before using it.
So technically all its children expressions are not needed.
I found the root cause. PromotePrecision overwrites Expression.genCode where is subexpression replace happens. So PromotePrecision skips subexpression elimination. I will submit another PR and include your test as co-author there. Thanks.
|
Do we have "subquery" here? Please update the description if it is not "subquery". |
viirya
left a comment
There was a problem hiding this comment.
Looks reasonable, although the description and the title confuse.
My mistake, should be SubExprEliminationState |
Updated, how about current? |
|
Close this according to #33103 |
What changes were proposed in this pull request?
For test case
failed when codegen
It's caused by when call CodeGenerator.getLocalInputVariableValues, expression match
SubExprEliminationStatebut is notVariableValue, then skip this whole expression, but when callsplitAggregateExpressions, since we need to find all input variables by this method, this will cause we skip some inputs.Here in this case , we put expression's children to stack too.
Why are the changes needed?
Fix Bug
Does this PR introduce any user-facing change?
No
How was this patch tested?
Added UT