From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: new GUC var: autovacuum_process_all_tables |
Date: | 2009-02-06 01:19:40 |
Message-ID: | 498B902C.1010502@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-02-06 01:27:07 | Re: new GUC var: autovacuum_process_all_tables |
Previous Message | Mykola Stryebkov | 2009-02-06 00:49:48 | create database warning |