Hitesh Bhambhani <hitesh.bhambh...@asg.com> wrote: > Could you give an example of what an 'extraordinary circumstance' > would be? Normal vacuums will remove old tuples (versions of rows) which can no longer be seen by any transaction, and make that space available for re-use within the PostgreSQL files. It will not normally give space back to the OS, but that's usually a *good* thing, because normally the space will soon be needed again by PostgreSQL, and it would be less efficient to constantly be giving space back and allocating it again. If you neglect to vacuum aggressively enough, or do a mass UPDATE or DELETE which affects a large percentage of your rows, without anticipating that you will need that space again soon, you might want to do aggressive maintenance to shrink the PostgreSQL files. VACUUM FULL will move tuples around within the table to free up space at the end so that it can be released. But wait -- you probably *still* don't want to use VACUUM FULL, because it is *very* slow and will bloat your indexes, requiring a REINDEX to restore decent performance. CLUSTER will rewrite the table without dead space and will rebuild the indexes -- usually much faster than VACUUM FULL. But CLUSTER needs room for a second copy of the table in order to copy it. If you have a very bloated table which you want to shrink and you don't have room for a second copy of it, *that* is the time to consider VACUUM FULL (usually followed by REINDEX). If you ever find you *do* need to run VACUUM FULL, you probably need to re-evaluate your maintenance procedures to see how you can avoid having to do it again. -Kevin
-- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
