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 по дате отправления:

Предыдущее
От: "Matthew T. O'Connor"
Дата:
Сообщение: Re: pg_autovacuum next steps
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SET WITHOUT CLUSTER patch