sql: avoid an allocation when running subqueries in some cases #126509
Conversation
![blathers[crl]](https://avatars.githubusercontent.com/in/59700?s=40&u=373d9101a12edc3847d2fb6ae78e3adcfb4ca41e&v=4){kind=avatar}
|
It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR? 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
|
This change is |
This commit reuses recently added `DatumAlloc` to the planner when creating the tuple that is the result of a subquery evaluation in order to reduce allocations. In a profile obtained from a customer I observed this allocation to be about 2% of all allocated objects. Release note: None
yuzefovich
force-pushed
the
subquery-alloc
branch
from
73827be to
c23ce43
Compare
There was a problem hiding this comment.
Reviewed 3 of 3 files at r1, all commit messages.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @yuzefovich)
pkg/sql/distsql_running.go line 1885 at r1 (raw file):
toAppend = row[0] } else { toAppend = planner.datumAlloc.NewDTuple(tree.DTuple{D: row})
So this will reduce allocations as long as subqueries return more than one row, correct?
There was a problem hiding this comment.
TFTR!
bors r+
Reviewable status:
pkg/sql/distsql_running.go line 1885 at r1 (raw file):
Previously, mgartner (Marcus Gartner) wrote…
So this will reduce allocations as long as subqueries return more than one row, correct?
IIUC this will reduce allocations when multiple rows could be returned, even if one is actually returned, in exec.SubqueryAnyRows / rowexec.SubqueryExecModeAllRowsNormalized execution mode.
This commit reuses recently added
DatumAllocto the planner when creating the tuple that is the result of a subquery evaluation in order to reduce allocations. In a profile obtained from a customer I observed this allocation to be about 2% of all allocated objects.Epic: None
Release note: None