Thank you Alvaro,
On 15/05/07 18:53 -0400, Alvaro Herrera wrote:
>Instead of waiting a month for the time when you can take the
>application offline (thus accumulating a month's worth of dead tuples),
>run a non-full vacuum more often (say, once a day or more). It doesn't
>lock the table so the app can continue to be online while it runs.
Yes, it is vacuumed non-full regularly. However, for some reason,
only a full vacuum will recover the space.
>If you have too many dead tuples and are desperate to get the table in a
>reasonable non-bloated state, try CLUSTER instead of VACUUM FULL. It
>might finish faster.
1. If I am running vacuum full on the database as:
vacuum full verbose;
without specifying a table, if I interrupt it, will the vacuuming of
the other tables that have already been vacuumed be undone? How
far is vacuuming rolled back if I interrupt it in this case?
2. If I interrupt the vacuum, and run cluster, how long do you think
cluster might take relative to a full vaccuum? Is it likely to
save disk space? (since that is the aim rather than speeding things
up)
The value of reltuples and relpages for this table are: reltuples:
572208, relpages 187502
3. This is PostgreSQL 7.3.8.
--
Nick Urbanik RHCE http://nicku.org nicku@nicku.org
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
