Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: > Silvio Brandani <silvio.brandani@xxxxxxxxxxx> wrote: >> we have develop a script to execute the vacuum full on all tables > Vacuum full is more of a recovery / offline command and is to be > used sparingly, especially before 9.0. And before 9.0, most of the situations where you might reasonably consider VACUUM FULL, you were better off with CLUSTER. >> very big database , since it is a 24 x 7 available system we have >> not a timeframe to exec the vacuum full. > > Is there a reason you're avoiding autovacuum and tuning it to keep > up? It's usually the better option. Even if you have a case for doing database vacuums during off-peak hours, you should almost certainly use autovacuum with settings at least as aggressive as the default. At our shop we configure autovacuum more aggressively than the default, to keep our small, volatile tables tidy, and run a vacuum of the entire database each night (which is, by the way, a very different thing than a VACUUM FULL). >> PostgreSQL 8.3.1 on x86_64-redhat-linux-gnu > > Is there a good reason for avoiding about two years of updates > (8.3.latest has a lot of bug fixes.) Yeah, this is important. See this page: http://www.postgresql.org/support/versioning Many of those fixes to 8.3 after 8.3.1 were to vacuum or autovacuum. You can poke around the release notes here: http://www.postgresql.org/docs/8.3/static/release.html If problems with autovacuum were what drove you toward VACUUM FULL, you should update and try autovacuum again. Going from 8.3.1 to 8.3.12 is pretty painless and very safe -- just read the release notes for details on what types of indexes need to be rebuilt after the update. (That probably won't affect you, but you should check.) -Kevin -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
