Skip site navigation (1) Skip section navigation (2)

Re: Modifying TOAST thresholds

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Browne <cbbrowne(at)acm(dot)org>, Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Modifying TOAST thresholds
Date: 2007-04-03 02:23:57
Message-ID: 14092.1175567037@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Chris Browne <cbbrowne(at)acm(dot)org> writes:
> tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
>> ... tuning the TOAST parameters seems like
>> something we understand well enough already, we just need to put some
>> cycles into testing different alternatives.  I would have no objection
>> to someone working on that during April and delivering a final patch
>> sometime before beta.

> Here's a "drafty" patch that *tries* to do this using a GUC variable;
> it passes some interactive testing.

I came across a couple of issues while fooling with decoupling
TOAST_TUPLE_THRESHOLD from TOAST_MAX_CHUNK_SIZE:

* Should TOAST_TUPLE_TARGET be configurable separately from
TOAST_TUPLE_THRESHOLD?  It certainly doesn't make sense for the target
to be larger, but perhaps it is sane to want it to be smaller.

* There's a hardwired assumption in the system that
TOAST_TUPLE_THRESHOLD is invariant: we do not create a toast table at
all when we can prove that the maximum tuple width is less than
TOAST_TUPLE_THRESHOLD (see needs_toast_table() in toasting.c).
Clearly this will not do if TOAST_TUPLE_THRESHOLD can be changed.
Should we abandon the notion altogether, and create a toast table
anytime the table contains any toastable types?  Or should we revel
in configurability, and allow CREATE TABLE/ALTER TABLE behavior to vary
depending on the current threshold setting?  We'd have to fix the
toaster routines to not try to push stuff out-of-line when there is no
out-of-line to push to ... but I think we probably had better do that
anyway for robustness, if we're allowing any variability at all in these
numbers.

Comments?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-04-03 02:29:21
Subject: Re: Feature thought: idle in transaction timeout
Previous:From: Bruce MomjianDate: 2007-04-03 02:17:19
Subject: Re: Feature thought: idle in transaction timeout

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group