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.
regards, tom lane
