On Tue, Aug 23, 2011 at 4:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> What I think would be really interesting is a way to make this work >> when the table *isn't* empty. In other words, have a COPY option that >> (1) takes an exclusive lock on the table, (2) writes the data being >> inserted into new pages beyond the old EOF, and (3) arranges for crash >> recovery or transaction abort to truncate the table back to its >> previous length. Then you could do fast bulk loads even into a table >> that's already populated, so long as you don't mind that the table >> will be excusive-locked and freespace within existing heap pages won't >> be reused. > > What are you going to do with the table's indexes?
Oh, hmm. That's awkward. I suppose you could come up with some solution that involved saving preimages of each already-existing index page that was modified until commit. If you crash before commit, you truncate away all the added pages and roll back to the preimages of any modified pages. That's pretty complex, though, and I'm not sure that it would be enough of a win to justify the effort. It also sounds suspiciously like a poor-man's implementation of a rollback segment; and if we ever decide we want to have an option for rollback segments, we probably want more than a poor man's version. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
