Re: Virtual tuple slots versus TOAST: big problem

On 11/20/2005 11:23 AM, Tom Lane wrote:

> Simon Riggs <simon@2ndquadrant.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@Yahoo.com #