On Fri, Jun 3, 2011 at 2:17 PM, Robert Haas <robertmh...@gmail.com> wrote:
> I've now spent enough time working on this issue now to be convinced > that the approach has merit, if we can work out the kinks. Yes, the approach has merits and I'm sure we can work out the kinks. > As you can see, this works out to a bit more than a 4% improvement on > this two-core box. I also got access (thanks to Nate Boley) to a > 24-core box and ran the same test with scale factor 100 and > shared_buffers=8GB. Here are the results of alternating runs without > and with the patch on that machine: > > tps = 36291.996228 (including connections establishing) > tps = 129242.054578 (including connections establishing) > tps = 36704.393055 (including connections establishing) > tps = 128998.648106 (including connections establishing) > tps = 36531.208898 (including connections establishing) > tps = 131341.367344 (including connections establishing) > > 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%. Congratulations. I believe that is realistic based upon my investigations. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
