Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> writes: > Begin a transaction and free the first chunk (2 tuples in this case, but > obviously many more in a real case): > ----------- > ..473612058 > ----------- > Use that freed space to store the first ordered tuples: > ----------- > 014736.2.58 > ----------- > Commit, and when the last transaction to which the "." tuples above are > still visible completes mark them as free with VACUUM or similar. > ----------- > 014736 2 58 > ----------- Oh, the problem is that you're misexplaining this. You can't do it like that: you can't overwrite the moved-up "." tuples until after they aren't visible to any other transaction. So you need two transactions to do the above. I'm not sure if you need two "wait for all others" or just one --- it's not clear to me what's the urgency of clearing out the moved-down tuples after they're moved down. (You *would* want to vacuum every so often, but this is to reclaim index space, not so much heap space because you'll reuse that anyway.) Anyway I think the main practical problem would be with deadlocks against other transactions trying to update/delete tuples at the same times you need to move them. Dealing with uncommitted insertions would be tricky too --- I think you'd need to wait out the inserting transaction, which would add more possibilities of deadlock. regards, tom lane
