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 #
