Simon Riggs <simon@2ndquadrant.com> writes:
> On Mon, 2006-06-26 at 16:48 +0200, Martijn van Oosterhout wrote:
>> Anyway, I think it's a good idea. Most places in the backend after the
>> SeqScan/IndexScan node really don't care about most of the header
>> fields and being able to drop them would be nice.
> I understood Tom meant to do this only for HashAgg and Tuplestore. Tom,
> is it possible to extend this further across the executor as Martijn
> suggests? That would be useful, even if it is slightly harder to measure
> the benefit than it is with the can-spill-to-disk cases.
There isn't any benefit except where we collect lots of tuples, which is
to say tuplesort/tuplestore/tuplehashtable. In other places in the
executor, there's basically only one transient tuple in existence per
plan node; jumping through hoops to save 16 bytes per plan node is just
silly. (What's more, as of 8.1 most of those tuples will be in "virtual
tuple" format anyway, and so the optimization wouldn't make any
difference at all...)
> IMHO it would be better to call the format TupleWithoutVisibilityData so
> its very clear that accessing the visibility fields aren't present and
> any attempt to access them would be a mistake. TruncatedTuple isn't
> clear about what's missing or its consequences.
I'm not wedded to "TruncatedTuple", but I don't like your suggestion
better; it presumes too much about what the difference might be between
truncated and full tuples. Even today, I don't think
"TupleWithoutVisibilityData" makes it clear that t_ctid is missing;
and down the road there might be other header fields that we don't need
to have in in-memory tuples. Another small problem is that given our
naming conventions for structs vs pointers to structs, using "Data" as
the last word of a struct name is a bad idea --- for consistency,
pointers to it would be typedef TupleWithoutVisibility, which seems a
bit weird. For consistency with the existing struct names, I think we
need to choose a name of the form "<adjective>Tuple".
I thought for awhile about MemoryTuple (as contrasted to HeapTuple) but
that seems too generic. Any other thoughts?
regards, tom lane
