Re: new GUC var: autovacuum_process_all_tables

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: new GUC var: autovacuum_process_all_tables
Дата
Msg-id 1233871969.4500.602.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответ на Re: new GUC var: autovacuum_process_all_tables  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: new GUC var: autovacuum_process_all_tables  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
On Thu, 2009-02-05 at 18:54 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > 
> > On Thu, 2009-02-05 at 18:25 -0300, Alvaro Herrera wrote:
> > 
> > > So you're not aware that we're doing away with pg_autovacuum for good?
> > > It's going to be replaced by reloptions, i.e.
> > > ALTER TABLE foo SET (autovacuum_enabled = false);
> > > 
> > > Obviously there's no way to add a "catchall" setting.
> > 
> > Seems like a bad plan then. How do you reconcile those conflicting
> > requirements?
> 
> I don't see them as conflicting; I see yours as a missing feature,
> namely the ability to add tables to an autovacuum "group", which could
> have settings attached.  Being able to do that is the whole point of
> moving settings to reloptions.

So your changes will allow these?

ALTER DATABASE foo SET (autovacuum_enabled = false);
ALTER SCHEMA foo SET (autovacuum_enabled = false);

CREATE TABLE GROUP foo_group;
ALTER TABLE foo SET TABLE GROUP foo_group;
ALTER TABLE foo2 SET TABLE GROUP foo_group;
ALTER TABLE GROUP SET (autovacuum_enabled = false);

Hopefully the grouping of tables is not purely related to AV?

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: new GUC var: autovacuum_process_all_tables
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: new GUC var: autovacuum_process_all_tables