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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-04-03 08:56:00 | Re: CheckpointStartLock starvation |
Previous Message | Simon Riggs | 2007-04-03 07:55:56 | Re: Interaction of PITR backups andBulkoperationsavoiding WAL |