Scott Marlowe <scott.marlowe@gmail.com> wrote:
> Silvio Brandani <silvio.brandani@tech.sdb.it> 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
