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

Re: Modifying TOAST thresholds

From: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Chris Browne" <cbbrowne(at)acm(dot)org>,"Jan Wieck" <JanWieck(at)Yahoo(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Modifying TOAST thresholds
Date: 2007-04-03 08:21:11
Message-ID: E1539E0ED7043848906A8FF995BDA57901E7B4FB@m0143.s-mxs.net (view raw or flat)
Thread:
Lists: pgsql-hackers
> > ... 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.
> 
> Actually, upon looking closely at the toast code, it already 
> does the right thing when there's no toast table.  Good on 
> someone for getting that right.  But we still need to think 
> about whether it's sane for CREATE/ALTER TABLE to condition 
> the create-a-toast-table decision on a parameter that may now 
> be changeable.

I think it is ok to decide during creation with current settings.
When a user wants a toast table that has not been created we can direct
them to use some dummy "alter table ... set storage ..." and create a
toast 
table if it does not exist (and the new settings opt for one).

And a new threshold has immediate consequences for inline compression,
so a change is not ignored. 

Andreas

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2007-04-03 08:56:00
Subject: Re: CheckpointStartLock starvation
Previous:From: Simon RiggsDate: 2007-04-03 07:55:56
Subject: Re: Interaction of PITR backups andBulkoperationsavoiding WAL

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