Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Sep 16, 2009 at 9:35 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Simon Riggs <si...@2ndquadrant.com> writes: >>>> * 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. > > Yeah, I was just wondering about that myself. Seems like there would > be lots of situations where short exclusive-lock intervals could be > tolerated, even though not long ones.
That was my thinking. The tuple moving can block if another backend is doing updates concurrently, and the moving can block other backends from updating (and cause serialization errors). But that seems like a perfectly acceptable limitation that we can simply document. Surely it's better than taking an ExclusiveLock. > So that's another argument > for being able to set an upper bound on how many tuples get moved > per call. Yeah, that would alleviate it. We could write a client utility to call it repeatedly, and perhaps VACUUMs in between, to make it easier to use. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
