Re: "Truncated" tuples for tuple hash tables
От | Simon Riggs |
---|---|
Тема | Re: "Truncated" tuples for tuple hash tables |
Дата | |
Msg-id | 1151345856.2479.44.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: "Truncated" tuples for tuple hash tables (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: "Truncated" tuples for tuple hash tables
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: