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: 937d27e10901030259v3b170cb5he51eb60308f346c3@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
grow.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

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