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 <firstname.lastname@example.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
Description: Digital signature