On 6/7/07, Jim C. Nasby <decibel@decibel.org> wrote:
> On Mon, Jun 04, 2007 at 11:04:26AM -0400, Alvaro Herrera wrote:
> > The launcher is set up to wake up in autovacuum_naptime seconds at most.
> > So if the user configures a ridiculuos time (for example 86400 seconds,
> > which I've seen) then the launcher would not detect the postmaster death
Is there some threshold after which we should have PostgreSQL emit a
warning to the effect of "autovacuum_naptime is very large. Are you
sure you know what you're doing?"
> Yeah, I've seen people set that up with the intention of "now autovacuum
> will only run during our slow time!". I'm thinking it'd be worth
> mentioning in the docs that this won't work, and instead suggesting that
> they run vacuumdb -a or equivalent at that time instead. Thoughts?
Hmmm... it seems to me that points new users towards not using
autovacuum, which doesn't seem like the best idea. I think it'd be
better to say that setting the naptime really high is a Bad Idea.
Instead, if they want to shift maintenances to "off hours" they should
consider using a cron job that bonks around the
pg_autovacuum.vac_base_thresh or vac_scale_factor values for tables
they don't want vacuumed during "operational hours" (set them really
high at the start of operational hours, then to normal during off
hours). Tweaking the enable column would work too, but they presumably
don't want to disable ANALYZE, although it's entirely likely that new
users don't know what ANALYZE does, in which case they _really_ don't
want to disable it.
This should probably be very close to a section that says something
about how insufficient maintenance can be expected to lead to greater
performance issues than using autovacuum with default settings.
Assuming we believe that to be the case, which I think is reasonable
given that we are now defaulting to having autovacuum enabled.
Andrew