On 11/20/2005 11:23 AM, Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> 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. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
