-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fix logical plan serialization #3574
Conversation
@alamb @andygrove This feels like a bit of hacky special casing but seemed like the least insrusive way to deal with this. If optimizers can change expression names in general though this could come up in other places w/r/t serde of aggregation plans where we rely explicitly on the expression name. |
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 agree this seems a little icky (like it is treating the symptom rather than the root cause) but I think it is tested and seems reasonable to me
I wish I had a better story for you |
I believe this PR is going to fail its checks until is it merged to include #3576 |
Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
78e49b5
to
98bf2e2
Compare
Benchmark runs are scheduled for baseline = 634d912 and contender = 488be64. 488be64 is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
I wonder if #3568 could be related |
Yeah, if I understand that ticket correctly then it's the same underlying issue |
Which issue does this PR close?
Closes #3555
Rationale for this change
Currently round-trip logical plan serialization is broken for some aggregation queries. This happens when the
TypeCoercion
optimizer casts literal values in aggregate function expressions and then the const evaluator optimizes out the cast (replacing with a literal for the casted value). This effectively changes the expression name and causes a mismatch when rebuilding the plan after deserialization.What changes are included in this PR?
In
TypeCoercion
special-case the handling of aggregation function expressions to make sure we alias back to the original expression name if it has changed. This should ensure the schema is still valid and the plan can be rebuilt from its serialized representation.Are there any user-facing changes?
no
no