From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: reloptions and toast tables |
Date: | 2008-12-20 23:48:42 |
Message-ID: | 20081220234842.GD3989@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Euler Taveira de Oliveira wrote:
> Alvaro Herrera escreveu:
> > I'm wondering if I should just allow all reloptions (including
> > fillfactor) or just the autovacuum ones.
> >
> Yes, please. But i'm afraid it is too 'complicated' to expose
> 'pg_toast.pg_toast_xxxxx' to user (but we can solve it with good
> documentation). What about xxx_toast reloptions? The con is that we need to
> add 2 reloptions if the new reloption is table-related.
Hmm, now that I look at that again, it seems a very bad idea.
Your idea of having separate options for the toast table, I take you
mean having toast_autovacuum_enabled and such, and they would be
attached to the main table? If that's what you mean, I admit I don't
like it either -- we would duplicate the size of the reloptions table
for no good reason :-(
It would be better to have a separate command, that doesn't force the
user to look up the toast table name. I'm not sure what such a syntax
would actually look like though. I'm open to ideas.
ALTER TABLE foo SET (TOAST autovacuum_enabled = false);
ALTER TABLE foo SET (toast.autovacuum_enabled = false);
ALTER TABLE foo TOAST SET (autovacuum_enabled = false);
ALTER TABLE foo SET TOAST (autovacuum_enabled = false);
...?
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-12-20 23:58:15 | Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major |
Previous Message | Euler Taveira de Oliveira | 2008-12-20 23:26:17 | Re: reloptions and toast tables |