Re: "Truncated" tuples for tuple hash tables - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: "Truncated" tuples for tuple hash tables
Date
Msg-id 1151351185.2479.79.camel@localhost.localdomain
Whole thread Raw
In response to Re: "Truncated" tuples for tuple hash tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "Truncated" tuples for tuple hash tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2006-06-26 at 14:36 -0400, Tom Lane wrote:
> 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 

OK, see that... 

> I thought for awhile about MemoryTuple (as contrasted to HeapTuple) but
> that seems too generic.  Any other thoughts?

I like MemoryTuple but since we only use it when we go to disk...

ExecutorTuple, MinimalTuple, DataOnlyTuple, MultTuple, TempFileTuple

Pick one: I'm sorry I opined.

--  Simon Riggs EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: vacuum, performance, and MVCC
Next
From: Bruce Momjian
Date:
Subject: Re: Overhead for stats_command_string et al, take 2