On Thu, Jun 07, 2007 at 12:13:09PM -0700, Andrew Hammond wrote:
> 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
I think we could easily word it so that it's clear that just letting
autovacuum do it's thing is preferred.
> 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.
That sounds like a rather ugly solution, and one that would be hard to
implement; not something to be putting in the docs.
--
Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)