From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: "Truncated" tuples for tuple hash tables |
Date: | 2006-06-26 19:46:24 |
Message-ID: | 1151351185.2479.79.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2006-06-26 at 14:36 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-06-26 19:47:16 | Re: Overhead for stats_command_string et al, take 2 |
Previous Message | Tom Lane | 2006-06-26 19:10:03 | Re: Overhead for stats_command_string et al, take 2 |