On Thu, April 27, 2006 18:41, Markus Schaber wrote: > Just for illustration: One of the most questions on the postgresql > performance ist is why batch inserts / updates are so slow. The two > answers are usually "bundle several thousands in a transaction" and "use > COPY if possible", and the speed gain factors can exceed 1000.
(On a side note, if you want to use COPY, look at the tablestream class hierarchy in libpqxx) > For read-only SELECTs that return bunches of data, it doesn't make much > difference, performance-wise. Come to think of it... If every statement executed outside any transaction is automatically wrapped in its own transaction, any performance benefit would still go to the transaction! >> The 2.6 series adds an additional transaction type, subtransaction, that >> acts like a regular transaction but lives inside another transaction >> (which may in turn be a subtransaction). Proper nesting is enforced. > > Okay, I found it. Its sparsely documented, though, but that should be no > problem. Subtransactions are the most commonly used use of savepoints, > and are capable of error recovery, so that's fine. It's still fairly new, so be gentle and *please* speak up if you run into a problem with it! Jeroen _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
