sql: use IndexFetchSpec for zigzag join#78295
Conversation
|
This change is |
yuzefovich
left a comment
There was a problem hiding this comment.
Very nice cleanup!
Reviewed 2 of 2 files at r1, 5 of 5 files at r2, 27 of 27 files at r3, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @mgartner and @RaduBerinde)
pkg/sql/rowexec/zigzagjoiner_test.go, line 232 at r3 (raw file):
}, { FetchSpec: makeFetchSpec(t, empty, "d", "a,b,d"),
This should be highRangeDesc.
pkg/sql/rowexec/zigzagjoiner_test.go, line 248 at r3 (raw file):
Sides: []execinfrapb.ZigzagJoinerSpec_Side{ { FetchSpec: makeFetchSpec(t, empty, "c", "a,b,c"),
Here the order of empty and highRangeDesc is switched.
mgartner
left a comment
There was a problem hiding this comment.
🤩
Reviewed 2 of 2 files at r1, 5 of 5 files at r2, 27 of 27 files at r3, all commit messages.
Reviewable status:
The zig-zag joiner code still uses `Bytes` instead of `EncodedKey` for the encoded key. This works because the fixed values are encoded using VALUE encoding, and the value encodings are the same for `DBytes` and `DEncodedKey`. This commit updates the zigzag joiner to use the correct `EncodedKey` type. The code no longer needs to special case inverted indexes - with the addition of support for `EncodedKey` in `keyside.Encode`, the general code path can now be used. Release note: None
This change cleans up the zig-zag joiner spec: we move the per-side information into a Side sub-message and use a list of Sides instead of many parallel lists. Other misc cleanup in the zigzag joiner code is included. Release note: None
This commit changes the zigzag joiner to use IndexFetchSpec for the two sides instead of table and index descriptors. The internal schema of the zigzag joiner is changed to match the fetched columns, simplifying the execution code. This change necessitates fixes on the planning side - we weren't determining the necessary scan columns correctly (this wasn't a problem when the internal schema had all table columns and we were relying on the execution layer to figure out what is needed). Release note: None
772e76c to
d8710a0
Compare
RaduBerinde
left a comment
There was a problem hiding this comment.
TFTRs!
Reviewable status:
pkg/sql/rowexec/zigzagjoiner_test.go, line 232 at r3 (raw file):
Previously, yuzefovich (Yahor Yuzefovich) wrote…
This should be
highRangeDesc.
Done.
pkg/sql/rowexec/zigzagjoiner_test.go, line 248 at r3 (raw file):
Previously, yuzefovich (Yahor Yuzefovich) wrote…
Here the order of
emptyandhighRangeDescis switched.
Done.
|
bors r+ |
|
Build succeeded: |
rowexec: follow-up cleanup for EncodedKey in zigzagjoiner
The zig-zag joiner code still uses
Bytesinstead ofEncodedKeyforthe encoded key. This works because the fixed values are encoded using
VALUE encoding, and the value encodings are the same for
DBytesandDEncodedKey.This commit updates the zigzag joiner to use the correct
EncodedKeytype. The code no longer needs to special case inverted indexes -
with the addition of support for
EncodedKeyinkeyside.Encode, thegeneral code path can now be used.
Release note: None
sql: clean up ZigZagJoinerSpec
This change cleans up the zig-zag joiner spec: we move the per-side
information into a Side sub-message and use a list of Sides instead of
many parallel lists. Other misc cleanup in the zigzag joiner code is
included.
Release note: None
sql: use IndexFetchSpec for zigzag join
This commit changes the zigzag joiner to use IndexFetchSpec for the
two sides instead of table and index descriptors. The internal schema
of the zigzag joiner is changed to match the fetched columns,
simplifying the execution code.
This change necessitates fixes on the planning side - we weren't
determining the necessary scan columns correctly (this wasn't a
problem when the internal schema had all table columns and we were
relying on the execution layer to figure out what is needed).
Release note: None