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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
