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.
>
> Unlike the case with sort temp files, it's important to be able to
> access the stored data without moving/copying it. So, not wishing to
> duplicate all the tuple access machinery we have already, I'm
> envisioning a compromise design that leaves a couple bytes on the table
> but looks enough like a standard tuple to be directly usable.
I considered this, but ran into the problem that heap_getattr fell back
to fastgetattr, which wouldn't know what kind of tuple it was given.
Now, if you're going to add a special heap_getattr for these tuples,
then ofcourse there's no problem.
Maybe create a version of heap_getattr that takes the fallback function
as a parameter?
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.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.