Re: reloptions and toast tables - Mailing list pgsql-hackers

From Dave Page
Subject Re: reloptions and toast tables
Date
Msg-id 937d27e10901030259v3b170cb5he51eb60308f346c3@mail.gmail.com
Whole thread Raw
In response to Re: reloptions and toast tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: reloptions and toast tables  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Wed, Dec 31, 2008 at 9:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.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


pgsql-hackers by date:

Previous
From: "Stephen R. van den Berg"
Date:
Subject: Re: Significantly larger toast tables on 8.4?
Next
From: KaiGai Kohei
Date:
Subject: Re: generic reloptions improvement