Re: Vacuum is needed or not?

http://www.postgresql.org/docs/8.0/interactive/maintenance.html

Read all, in order to understand the following quote:

"

Since periodic VACUUM runs are needed anyway for the reasons described
earlier, it's unlikely that any table would not be vacuumed for as long as a
billion transactions. But to help administrators ensure this constraint is
met, VACUUM stores transaction ID statistics in the system table pg_database.
In particular, the datfrozenxid column of a database's pg_database row is
updated at the completion of any database-wide VACUUM operation (i.e.,
VACUUM that does not name a specific table). The value stored in this field
is the freeze cutoff XID that was used by that VACUUM command. All normal
XIDs older than this cutoff XID are guaranteed to have been replaced by
FrozenXID within that database. A convenient way to examine this information
is to execute the query

SELECT datname, age(datfrozenxid) FROM pg_database;

"

Best wishes,
Guido

On 1/5/06, Jaime Casanova <systemguards(at)gmail(dot)com> wrote:
>
> On 1/5/06, Szabolcs BALLA <szballa(at)confinsystems(dot)com> wrote:
> >
> >
> VACUUM is needed at least every billion transactions...
>
> execute it in a
> > script periodically... if you are in doubt if you need
> VACUUM then you need
> > it urgently, execute it right now!!!
>
> >
> > yes, and i running every weekend a full analyze, but actually i think
> it's
> > need again, but just for feel i couldn't stop the server.
> > I need evidence. (oldspice rulez ;))
> >
> > Szabek
>
> a plain VACUUM (without full) is enough in most cases... and you don't
> need to stop the server for a plain VACUUM...
>
> --
> regards,
> Jaime Casanova
> (DBA: DataBase Aniquilator ;)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
"Adopting the position that you are smarter than an automaticoptimization
algorithm is generally a good way to achieve lessperformance, not more" -
Tom Lane.