From: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_autovacuum next steps |
Date: | 2004-03-22 15:41:52 |
Message-ID: | 1079970112.14960.20.camel@zeudora.zeut.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2004-03-22 at 07:25, Richard Huxton wrote:
> On Monday 22 March 2004 03:36, Matthew T. O'Connor wrote:
> > 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.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.
If pg_autovacuum was being designed to live forever as a client app,
then I agree admins having a choice would be good. But as we are going
to eventually move any auto_vacuum data and settings into the system
tables (when autovacuum is part of the system), I don't see the need to
expend the extra cycles, especially since people seem to be pushing hard
for autovacuum to be a backend function sooner rather than later.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-03-22 15:51:42 | Re: pg_autovacuum next steps |
Previous Message | Tom Lane | 2004-03-22 15:39:16 | Re: SET WITHOUT CLUSTER patch |