On Wed, April 26, 2006 17:50, Markus Schaber wrote: > I'm just reading the pqxx documenation online, and the following > questions arised: > > http://thaiopensource.org/devprojects/libpqxx/doc/2.6.3/html/Tutorial/ch02.html > states that "nontransaction" gives the best performance. (I believe this > to be equal to "autocommit on" in psql and jdbc.) However, from own > experience and reading the [email protected] list, > bundling several actions together in an transaction usually improves the > performance, because of the transaction overhead (including sync()ing > the data out to the disks). So what's the reason for pqxx to give better > performance without transactions?
Right. I haven't had time to complete or maintain the tutorial, unfortunately, so it's not that good. It should state that nontransaction is likely to be faster *for transactions that don't modify the database*. I've just changed this to reflect what you say--thanks! > The same page also has the to_string() and from_string() methods. This > leads me to the assuption that libpqxx does only support canonical text > representations, and not canonical binary representations for data > transfer to the backend. Is that correct? And is there a way to "plug > in" extension data types, like PostGIS? All data except large objects and prepared statement parameters (depending on backend support) are transferred as text. Supporting binary data transfer is a really big deal. I haven't played with custom data types, so I'm on thin ice here... But on the client-side, as long as you're converting to/from custom classes (or at least not to any of the types whose conversion is already supported), you can write your own string conversion functions and the various function templates should pick them up as if they were built in. http://thaiopensource.org/devprojects/libpqxx/doc/2.6.3/html/Tutorial/ch03s04.html > near the bottom: Transactions are aborted when database errors occur. > PostgreSQL 8.X support savepoints, and using them error recovery is > possible (like it is done py plpgsql exception mechanism). How does pqxx > support this? 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. > I have to add that I've got plenty of experience with jdbc, and psql > command line, but not with libpq yet. You shouldn't really need to, except for specifying connection parameters. Apart from that, and linking of course, libpq is completely hidden from view. Knowledge of libpq may both help and hurt when using libpqxx: it can help understand some mechanisms and conventions, but in other cases it can give a false impression of transparency. There's a lot of work going on on top of libpq that can trip you up if you assume that libpqxx works like libpq. Jeroen _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
