Re: new GUC var: autovacuum_process_all_tables
От | Josh Berkus |
---|---|
Тема | Re: new GUC var: autovacuum_process_all_tables |
Дата | |
Msg-id | 498B902C.1010502@agliodbs.com обсуждение исходный текст |
Ответ на | new GUC var: autovacuum_process_all_tables (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: new GUC var: autovacuum_process_all_tables
|
Список | pgsql-hackers |
Alvaro, First off, with over 200 GUC variables currently active, in general we should be looking to *eliminate* variables rather than adding them. So my personal bar for endorsing a new GUC is set pretty high. > Now, sometimes it might make more sense to keep it enabled but have it > only check for certain tables, and leave the majority of them disabled. > For this we'd have a separate GUC parameter, as in $SUBJECT (I'm not > wedded to the name), and have the user set autovacuum_enabled=true via > reloptions to enable it. I can't imagine, nor have I encountered in the 3 years of consulting I did since Autovaccum became available, such a use case. Unless there's a real, critical use case for this which is common, I'm opposed to this GUC. On the other hand, I'd been keen on a runtime suset autovaccum=on/off which we could call from a cron job or the pgadmin scheduler in order to have maintenance windows. Unless that's already becoming possible? --Josh
В списке pgsql-hackers по дате отправления: