On Wed, Sep 16, 2009 at 9:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> The way I read the thread so far is that there are multiple >> requirements: > >> * Shrink a table efficiently - when time and space available to do so > > To be addressed by the CLUSTER-based solution (VACUUM REWRITE or > whatever we call it). > >> * Shrink a table in place - when no space available > > To be addressed by the UPDATE-style tuple-mover (which could be thought > of as VACUUM FULL rewritten to not use any special mechanisms). > >> * Shrink a table concurrently - when no dedicated time available > > Wishful thinking, which should not stop us from proceeding with the > solutions we know how to implement.
The UPDATE-style tuple-mover might work for this too, for certain workloads. If most of your transactions are short, and the server load is not too high, it might be OK to lock the table, move a few tuples, lock the table, move a few tuples, etc. Now if you have long-running transactions, not so much. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
