From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_autovacuum next steps |
Date: | 2004-03-22 12:25:34 |
Message-ID: | 200403221225.34454.dev@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Monday 22 March 2004 03:36, Matthew T. O'Connor wrote:
> 1. Per Database defaults and Per table Thresholds:
>
> There are differing opinions as to the best way to providing these this
> feature. The primary debate is where to save the configuration data. I
> see three options:
>
> 1.Store config data inside a special pg_autovacuum table inside
> existing databases that wants custom settings.
>
> 2.Use a config file. This would require some additional coding to add
> the required parsing, but is possible.
>
> 3.Create a pg_autovacuum database inside any cluster that wants to
> customize their settings.
>
> Since many people do not like tools that clutter their databases by
> adding tables, I think option 1 (adding a pg_autovacuum table to
> existing databases) is right out. Using a config file would be Ok, but
> would require additional parsing code. My preference is option 3.
I've nothing against #3 as a default, but can I put in a suggestion for 1 & 3,
or rather some setting definable at runtime/build-time that lets you select
database + schema for autovacuum to find its config data.
I might be wrong, but it strikes me as the sort of thing people running shared
environments will want to choose for themselves.
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2004-03-22 12:41:25 | optimiser questions |
Previous Message | Philip Warner | 2004-03-22 10:30:35 | Re: Custom format for pg_dumpall |