On Fri, 2007-02-02 at 15:11 -0500, Tom Lane wrote:
> 2. Fix TOAST_TUPLE_THRESHOLD and TOAST_TUPLE_TARGET to be correctly
> calculated (properly allowing for line pointers) and to be MAXALIGN
> multiples. The threshold value should be exactly the size of the
> largest tuple that you can put four of onto one page. Fix
> TOAST_MAX_CHUNK_SIZE so that it is *not* necessarily a MAXALIGN
> multiple, but rather causes the total length of a toast tuple to come
> out that way. This guarantees minimum space wastage on toast pages.
Jan suggested to me a while back that having a configurable toast
threshold would be a useful thing, when that table is also updated
reasonably frequently. ISTM like a good idea, so a prototype has been
written - nothing to do with Pavan's comments though. As you might
expect, it does help in cases where we would otherwise produce lots of
UPDATEd versions of a 1000 byte row, as well as on MIS queries that
often don't pay much attention to text strings.
This then allows the user some control over how much data gets toasted
out of the main row. Many applications have long text fields of 100s of
characters, for example a customer's stated, cleaned and previous
addresses might together be VARCHAR(750), yet we may also want to UPDATE
them regularly to store their current_balance.
TOAST_MAX_CHUNK_SIZE can be fixed, though TOAST_TUPLE_THRESHOLD and
TOAST_TUPLE_TARGET could be settable for a table using a WITH parameter.
It would seem like overkill to allow the threshold and target to differ
when setting the parameter.
If configurable, only MAXALIGNed values would be allowed.
Sounds like a good time to suggest making these values configurable,
within certain reasonable bounds to avoid bad behaviour.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com