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

Re: reloptions and toast tables

From: "Dave Page" <dpage(at)pgadmin(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, "Euler Taveira de Oliveira" <euler(at)timbira(dot)com>
Subject: Re: reloptions and toast tables
Date: 2009-01-03 10:59:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Dec 31, 2008 at 9:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Peter Eisentraut wrote:
>>> On Sunday 21 December 2008 01:48:42 Alvaro Herrera wrote:
>>>> 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);
>>> The last two don't appear to allow setting TOAST and non-TOAST options in one
>>> go.  I think it would be handy to allow that, though.
>> Agreed -- so I'm now playing with this version:
>> ALTER TABLE foo SET (TOAST autovacuum_enabled = false);
>> So the grammar modifications needed to accept that are attached.  The
>> support code is a lot messier than I'd like :-(
> This is not only really ugly, but 100% toast-specific.  The
> qualified-name approach ("toast.autovacuum_enabled") has at least
> a chance of being good for something else.  Or just make it
> toast_autovacuum_enabled and do the translation magic at some low
> level in the statement execution code.

Are we expecting this patch (or whatever it turns into) to go into
8.4? It was marked as WIP when feature freeze started and clearly
still is quite undefined at this stage.

The reason I raise this is that this is precisely the sort of patch
that has a major knock-on effect to the tools the many people expect
to be able to use with a new version of the server as soon as it's
released. Obviously we need our own freeze and beta periods prior to
that time which is already extremely tight as we wait for last minute
changes in the server that need support.  The last thing we need is
for something like the per-table vacuum settings interface to
redefined right before beta as that is likely to require a fair amount
of re-working.

This is something I think we need to be more mindful of as our
project, it's surrounding eco-system of tools and users expectations

Dave Page
EnterpriseDB UK:

In response to


pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2009-01-03 12:42:08
Subject: Re: generic reloptions improvement
Previous:From: Stephen R. van den BergDate: 2009-01-03 10:46:53
Subject: Re: Significantly larger toast tables on 8.4?

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