From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgreSQL(dot)org, Alexey Beschiokov <proforg(at)maloletka(dot)ru> |
Subject: | Re: Virtual tuple slots versus TOAST: big problem |
Date: | 2005-11-20 16:34:25 |
Message-ID: | 4380A591.10208@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/20/2005 11:23 AM, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>> On Sat, 2005-11-19 at 12:22 -0500, Tom Lane wrote:
>>> ... The problem is that given the
>>> current structure, that means changing the APIs of heap_insert and
>>> heap_update, or else making near-duplicate versions that take a
>>> TupleTableSlot instead of a bare tuple. Neither of these things seem
>>> real attractive.
>
>> We changed the heap_insert API for 8,1 so would it be a problem to
>> change it again for 8.2
>
> It's not so much heap_insert/update, it's simple_heap_insert/update,
> which are called in a *lot* of places. Nonetheless, we have made such
> changes before (the simple_xxx routines didn't exist at all a few years
> ago), so it's not out of the question to do it again.
>
> A more constrained change would just alter the tuptoaster API so that
> it hands back an entirely new tuple instead of scribbling on the header
> it's handed. This doesn't save any overhead but it fixes the problem
> in a reasonably robust way, instead of expecting callers to compensate.
> (I'm unconvinced that my quick hack of yesterday plugged all the holes.)
> We'd need to add a couple lines to the heapam.c routines to free the
> separately allocated tuples, but that's no big deal.
>
>> What is the performance loss/gain by waiting?
>
> It's really hard to tell, but in any case it's nil if the tuple isn't
> long enough to need toasting. So I'm not sure we should go through
> major pushups to change it.
Assuming that the saved header values don't need to be recomputed if the
tuple doesn't need to be toasted at all, I think that toasting is
expensive enough so that recomputing those values is hardly noticed.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-11-20 16:40:47 | Re: Virtual tuple slots versus TOAST: big problem |
Previous Message | Tom Lane | 2005-11-20 16:29:39 | Re: Returning multiple result sets |