Bruce Momjian wrote: > I just checked and pg_dump -d _doesn't_ place the INSERT's in a > transsaction. Seems it should, and perhaps add a: > > SET autocommit TO 'on' > > as well. Of course, that SET would fail when restoring to prior > releases, but they don't have autocommit off anyway so it can be > ignored. Comments? This would certainly speed up loads that use > INSERT.
I'm not sure that pg_dump is the right place to do this, unless it's something that can be turned on/off with a command line switch (remember that editing the file to delete or comment out the transaction commands isn't necessarily feasible). It seems to me that a DBA might want to have a bit more control over this behavior. So: if pg_restore or some other utility is used to perform the restore, then that utility should issue the BEGIN/END on behalf of the user. One reason I can think of for keeping manual control over the transaction is the case where one wishes to restore from multiple dumps. In that case, it could be very useful to issue a single transaction block around the entire thing, and to examine the restored data before actually committing the results, in case something doesn't look right. This is all complicated, of course, by commands which cannot occur within transactions, which is why I think a switch controlling this behavior is appropriate. I certainly don't have a problem with the default being that the transaction commands are issued in the dump, as long as it's a behavior that can be turned off. -- Kevin Brown [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
