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