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
yuzefovich
added
backport-23.2.x
|
This change is |
There was a problem hiding this comment.
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.
TFTR!
bors r+
Reviewable status:
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
EnsureDecodedwith 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