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

Re: PATCH: Update autovacuum to use reloptions, instead of a system catalog

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: Update autovacuum to use reloptions, instead of a system catalog
Date: 2009-02-18 12:31:08
Message-ID: 937d27e10902180431r45c66a58g94696956fa68e0e0@mail.gmail.com (view raw or flat)
Thread:
Lists: pgadmin-hackers
On Wed, Feb 18, 2009 at 7:45 AM, Ashesh Vashi
<ashesh(dot)vashi(at)enterprisedb(dot)com> wrote:
> Hi All,
>
> Please find the attached patch for "Update autovacuum to use reloptions,
> instead of a system catalog".

Thanks - patch applied.

> In "CREATE/ALTER TABLE", it also supports for toast.autovacuum* settings (as
> storage parameters),
> which I have not implemented currently.
> Do we need to give support for that?
> And if yes,

If you can add it in the next few days, then I think yes.

> 1. Which documents I need to read for that?

http://developer.postgresql.org/pgdocs/postgres/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS
?

It all looks pretty much the same as the work you've done though.

> 2. From which catalog tables, I can get the toast.autovacuum* settings.

I assume they go in pg_class.reloptions for the owner table. It should
be easy to test that.

> 3. How UI should look like?

Good question. What about having a tabset under the 'Custom
Autovacuum' checkbox, and have one page that shows the existing
options for the table, and one that shows the TOAST options?


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

In response to

Responses

pgadmin-hackers by date

Next:From: Ashesh VashiDate: 2009-02-18 13:24:29
Subject: Re: PATCH: Update autovacuum to use reloptions, instead of a system catalog
Previous:From: svnDate: 2009-02-18 12:25:18
Subject: SVN Commit by dpage: r7597 - trunk/pgadmin3/pgadmin/dlg

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