On Tue, Aug 23, 2011 at 4:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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