On Mon, Jun 6, 2011 at 2:49 PM, Josh Berkus <j...@agliodbs.com> wrote: > >> That's an improvement of about ~3.5x. According to the vmstat output, >> when running without the patch, the CPU state was about 40% idle. >> With the patch, it dropped down to around 6%. > > Wow! That's fantastic. > > Jignesh, are you in a position to test any of Robert's work using DBT or > other benchmarks? > > -- > Josh Berkus > PostgreSQL Experts Inc. > http://pgexperts.com >
Okay I tried it out with sysbench read scaling test.. Note I had tried that earlier on 9.0 http://jkshah.blogspot.com/2010/11/postgresql-90-simple-select-scaling.html And on that test I found that doing that test on anything bigger than 4 cores lead to decreased performance .. Redoing the same test with 100 users on 4 vCPU Virtual Machine with 8GB with 1M rows I get transactions: 17870082 (59566.46 per sec.) which is inline with the best number on 9.0. This test hardly had any idle CPUs. However where it made a huge impact was doing the same test on my 8 vCPU VM with 8GB RAM I get transactions: 33274594 (110914.85 per sec.) which is a whopping 1.8x scaling for 2x scaling (from 4 to 8 vCPU).. My idle cpu was less than 7% which when taken into consideration that the "useful" work is line with my expectations is really impressive.. (And plus the last time I did MySQL they were around 95K or so for the same test). Also note that in my earlier case 60K was the max irrespective of the hardware I threw at it.. For this fastlock patch that does not seem to be the problem anymore :-) This gain is impressive.. Next step DBT-2.. Regards, Jignesh Next step -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
