Re: pg_autovacuum next steps
От | Matthew T. O'Connor |
---|---|
Тема | Re: pg_autovacuum next steps |
Дата | |
Msg-id | 1079970112.14960.20.camel@zeudora.zeut.net обсуждение исходный текст |
Ответ на | Re: pg_autovacuum next steps (Richard Huxton <dev@archonet.com>) |
Список | 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.
В списке pgsql-hackers по дате отправления: