On Mon, 2006-06-26 at 16:48 +0200, Martijn van Oosterhout wrote:
> On Mon, Jun 26, 2006 at 10:36:00AM -0400, Tom Lane wrote:
> > While looking at the recently-noticed problem that HashAggregate nodes
> > store more columns of the input than they need to, I couldn't help
> > noticing how much of the hashtable space goes into HeapTuple header
> > overhead. A couple months ago we were able to get a useful improvement
> > in sorting by not storing unnecessary header fields in sort files, and
> > I'm strongly tempted to do the same in tuple hash tables.
> 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.
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.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com