On Sat, May 21, 2011 at 8:41 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Sat, May 21, 2011 at 5:31 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Sat, May 21, 2011 at 7:51 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> Another point is that parsing overhead is quite obviously not the >>> reason for the massive performance gap between one core running simple >>> selects on PostgreSQL and one core running simple selects on MySQL. >>> Even if I had (further) eviscerated the parser to cover only the >>> syntax those queries actually use, it wasn't going to buy more than a >>> couple points. >> >> Incidentally, prepared transactions help a lot. On unpatched master, >> with pgbench -T 300 -S -n: >> >> tps = 10106.900801 (including connections establishing) >> tps = 10107.015951 (excluding connections establishing) > > Are you sure that you actually ran that with -M prepared? The numbers > look suspiciously similar to the ones reported in your original email.
That's without -M prepared; the subsequent number (~18K) is the one with -M prepared. So prepared transactions increased throughput by about 80%, in this test. > For what it is worth, on my ancient hardware, the patched code is > slower than the unpatched just as often as it is faster, using -n -S > -T 300 on alternations between servers. Well, that's pretty interesting. The effect *appeared* to be small but consistent in my testing, but it could be I just got lucky; or the choice of architecture and/or OS might matter. -- 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
