On Thu, Jun 07, 2007 at 12:13:09PM -0700, Andrew Hammond wrote: > On 6/7/07, Jim C. Nasby <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
pgpcTAxuATxrP.pgp
Description: PGP signature