Re: new GUC var: autovacuum_process_all_tables
От | Simon Riggs |
---|---|
Тема | Re: new GUC var: autovacuum_process_all_tables |
Дата | |
Msg-id | 1233870348.4500.596.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: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? > > e.g. > > "ALL TABLES", autovacuum_enabled=false > > > > I don't really want more GUCs for every nuance of AV behaviour. > > In any case I fail to see how is this much different from a new GUC var. Rows in a table v. new parameters. We can allow endless table driven complexity. Adding my_little_nuance=on|off strains most people's patience. How would I specify that database A wants AV turned off, but database B wants it on? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: