On Fri, Jun 3, 2011 at 2:17 PM, Robert Haas <robertmhaas@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
