-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
rowexec: fix oid handling in merge join and zigzag join #123486
Conversation
This commit is a follow up fix to a4b6234 which fixed how we handle zero value Oid types. In particular, we now need to have the precise type information for Oid type family to display zero Oid correctly. Previously, we could have imprecise information in merge join and zigzag joins that was stored in the right-hand side EncDatum when it was decoded using the LHS type, and this is now fixed. I don't think other join types (hash join and lookup join) are susceptible to this since they do decoding at different points in time, so it's unlikely we'd get a similar mix up there. There is no release note since it seems like an edge case (comparing Oid types with different Oids in non-default row-by-row engine). Release note: None
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.
Nice fix! Just one suggestion/question.
Reviewed 4 of 4 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @yuzefovich)
pkg/sql/rowenc/encoded_datum.go
line 570 at r1 (raw file):
// CompareEx is the same as Compare but allows specifying a different type // schema for RHS row. func (r EncDatumRow) CompareEx(
[nit] Do you think it would be any simply to make sure we call EnsureDecoded
with the correct type before attempting to compare the datums?
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.
TFTR!
bors r+
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @DrewKimball)
pkg/sql/rowenc/encoded_datum.go
line 570 at r1 (raw file):
Previously, DrewKimball (Drew Kimball) wrote…
[nit] Do you think it would be any simply to make sure we call
EnsureDecoded
with the correct type before attempting to compare the datums?
This is actually what I tried first, but then I realized that there is a fast-path in EncDatum.Compare
where both sides have the same encoding - we just compare the encodings directly without having to decode each into tree.Datum
. It seems like a nice optimization that I didn't want to lose, so I decided to do the plumbing. I don't have any intuition about how important that fast-path is though.
This commit is a follow up fix to a4b6234 which fixed how we handle zero value Oid types. In particular, we now need to have the precise type information for Oid type family to display zero Oid correctly. Previously, we could have imprecise information in merge join and zigzag joins that was stored in the right-hand side EncDatum when it was decoded using the LHS type, and this is now fixed. I don't think other join types (hash join and lookup join) are susceptible to this since they do decoding at different points in time, so it's unlikely we'd get a similar mix up there.
There is no release note since it seems like an edge case (comparing Oid types with different Oids in non-default row-by-row engine).
Fixes: #123474.
Release note: None