Re: Performance with new nested-xacts code - Mailing list pgsql-hackers
From | Grant Finnemore |
---|---|
Subject | Re: Performance with new nested-xacts code |
Date | |
Msg-id | 40E3A409.1090806@guruhut.co.za Whole thread Raw |
In response to | Performance with new nested-xacts code (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
Hi Tom, As requested - although the results are all over the place... :-( One interesting factor in these tests is that the max tps without the new code was 74.7, with the new code, 85.8. This is a Sony Laptop, slow IDE disk, Fedora Core 2 [grant@localhost pgsql-HEAD]$ uname -a Linux localhost.localdomain 2.6.6-1.435 #1 Mon Jun 14 09:09:07 EDT 2004 i686 i686 i386 GNU/Linux ./bin/postmaster -F HTH. Regards, Grant -- PRE NESTED XACTS [grant@localhost pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 74.632059 (including connections establishing) tps = 74.710309 (excluding connections establishing) [grant@localhost pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 61.405658 (including connections establishing) tps = 61.471754 (excluding connections establishing) [grant@localhost pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 59.702545 (including connections establishing) tps = 59.754499 (excluding connections establishing) [grant@localhost pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 54.531685 (including connections establishing) tps = 54.584432 (excluding connections establishing) -- POST NESTED XACTS [grant@localhost pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 72.656915 (including connections establishing) tps = 72.732723 (excluding connections establishing) [grant@localhost pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 85.687383 (including connections establishing) tps = 85.822281 (excluding connections establishing) [grant@localhost pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 59.479127 (including connections establishing) tps = 59.540478 (excluding connections establishing) [grant@localhost pgbench]$ ./pgbench -c 5 -t 1000 bench starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 10 number of clients: 5 number of transactions per client: 1000 number of transactions actually processed: 5000/5000 tps = 51.675145 (including connections establishing) tps = 51.715526 (excluding connections establishing) Tom Lane wrote: [snip] > > Can anyone else reproduce these results? The test case I'm using is > pgbench -i -s 10 bench > followed by repeated > pgbench -c 5 -t 1000 bench > I've built PG with --enable-debug and --enable-cassert, and am running > with -F (fsync off) but otherwise absolutely factory-stock > postgresql.conf. The hardware is a not-so-new-anymore Dell P4 with > run-of-the-mill IDE disk drive, running RHL 8.0. Obviously none of this > is tuned at all, but the question is why did CVS tip get faster when it > should by rights be slower. >
pgsql-hackers by date: