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 [EMAIL PROTECTED] GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
pgpLUP2RGS30O.pgp
Description: PGP signature
