colmem: optimize SetAccountingHelper #68221
Conversation
|
This change is |
yuzefovich
force-pushed
the
set-accounting-helper
branch
from
c088d85 to
ca30226
Compare
There was a problem hiding this comment.
Are there any types that are of variable size, but the maximum size isn't much larger than the minimum? If so, we could just always use the maximum and overaccount, but avoid some of the overhead.
Reviewable status:
complete! 1 of 0 LGTMs obtained (waiting on @jordanlewis and @yuzefovich)
pkg/sql/colmem/allocator.go, line 526 at r1 (raw file):
// coldata.BatchSize(), this slice will never exceed coldata.BatchSize() in // size, and we choose to ignore it for the purposes of memory accounting. varSizeDatumSizes []int64
Might be a good idea to add a Close method that releases references to columns and nils out slices.
This commit optimizes recently introduced SetAccountingHelper in order to reduce the number of casts per row. Namely, we can perform the cast from `coldata.Vec` to a concrete vector only once when a new batch is allocated and store the concrete vectors to be used during the per-row accounting. In a single benchmark this showed an improvement of about 3%. Release note: None
yuzefovich
force-pushed
the
set-accounting-helper
branch
from
ca30226 to
9625656
Compare
There was a problem hiding this comment.
Interesting question. I've just looked over all baseDatumTypeSizes in tree/datum.go, and to me it seems like all variable size types are truly variable, with no upper bound. Also the variable size types that are not bytes-like nor decimals seem pretty out there (quite rare), so it's probably not worth thinking too much about them.
TFTR!
bors r+
Reviewable status:
pkg/sql/colmem/allocator.go, line 526 at r1 (raw file):
Previously, DrewKimball (Drew Kimball) wrote…
Might be a good idea to add a
Closemethod that releases references to columns and nils out slices.
Very good point, done.
|
Build succeeded: |
This commit optimizes recently introduced SetAccountingHelper in order
to reduce the number of casts per row. Namely, we can perform the cast
from
coldata.Vecto a concrete vector only once when a new batch isallocated and store the concrete vectors to be used during the per-row
accounting. In a single benchmark this showed an improvement of about
3%.
Release note: None