colexec: optimize CASE, AND, and OR projection operators #62925
Conversation
|
This change is |
There was a problem hiding this comment.
Reviewed 3 of 3 files at r1.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @jordanlewis)
There was a problem hiding this comment.
Reviewed 1 of 3 files at r1.
Reviewable status:
pkg/sql/colexec/and_or_projection_tmpl.go, line 170 at r1 (raw file):
o.origSel = o.origSel[:origLen] } copy(o.origSel, sel)
Should we encapsulate this pattern in a helper? 3 times is usually enough for me to pull the trigger.
Previously, in CASE, AND, and OR projection operators we would always allocate internal selection vectors of maximum capacity in the constructor. This is inefficient when the query processes only small data sets. This commit makes the allocations lazy and of tight sizes based on the batch lengths. Release note: None
There was a problem hiding this comment.
TFTRs!
bors r+
Reviewable status:
pkg/sql/colexec/and_or_projection_tmpl.go, line 170 at r1 (raw file):
Previously, cucaroach (Tommy Reilly) wrote…
Should we encapsulate this pattern in a helper? 3 times is usually enough for me to pull the trigger.
Good point, done.
There was a problem hiding this comment.
Reviewed 4 of 4 files at r2.
Reviewable status:
|
Build succeeded: |
Previously, in CASE, AND, and OR projection operators we would always
allocate internal selection vectors of maximum capacity in the
constructor. This is inefficient when the query processes only small
data sets. This commit makes the allocations lazy and of tight sizes
based on the batch lengths.
Addresses: #62212
Release note: None