Re: Virtual tuple slots versus TOAST: big problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org, Alexey Beschiokov <proforg(at)maloletka(dot)ru>, Jan Wieck <JanWieck(at)Yahoo(dot)com>
Subject: Re: Virtual tuple slots versus TOAST: big problem
Date: 2005-11-20 16:23:40
Message-ID: 28667.1132503820@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-11-20 16:29:39 Re: Returning multiple result sets
Previous Message Martijn van Oosterhout 2005-11-20 14:09:25 Re: Returning multiple result sets