Re: multi-threaded pgbench

This patch is wrapping up nicely.  I re-tested against the updated 
pgbench-mt_20090724 and now I get similar results whether or not 
--enable-thread-safety is enabled on Linux, so that problem is gone. 
Josh's successful Windows tests along with finding the bug he attached a 
patch to is also encouraging.

I re-ran my performance tests with the same basic setup (16 core system, 
database scale=10, read-only tests) but this time increased shared_buffers 
to 256MB just to see if results popped up significantly (they didn't).

Here's a comparison of the original pgbench select-only TPS against the 
new version using 1 thread:
    clients
threads    16    32    64    128
none    91763    69707    68465    63730
1    90797    70117    66324    63626

I ran these a few times and those are basically the same result.  If 
there's a regression using 1 threads instead of 1 process, which I thought 
I was seeing at one point with j=1/c=128, under closer investigation it 
would have to be much smaller than the run to run variation of pgbench 
because it vanished when I collected many runs of data.

Running the new pgbench with thread safety turned on:
    clients
threads    16    32    64    128
1    89503    67849    67120    63499
2    97883    91888    87556    84430
4    95319    96409    90445    83569
8    96002    95411    88988    82383
16    103798    95056    87701    82253
32    X    95869    88253    82253

Running it without thread safety turned on so it uses processes instead 
(this is the case I couldn't report on before):
    clients
threads    16    32    64    128
1    89706    68702    64545    62770
2    99224    91677    88812    82442
4    96124    96552    90245    83311
8    97066    96000    89149    83266
16    103276    96088    88276    82652
32    X    97405    90082    83672

Those two tables are also identical relative to the run to run pgbench 
noise.

This looks ready for a committer review to me, I'm happy that the patch 
performs as expected and it seems to work across two platforms.

To step back for a second, I'm testing a fairly optimistic situation--the 
standard RHEL 2.6.18 kernel which doesn't have any major issues here--and 
I see a decent sized speedup (>30%) in the worst case.  I've reported 
before that running pgbench on newer Linux kernels (>=2.6.23) is horribly 
slow, and sure enough the original results kicking off this thread showed 
the same thing:  only 11600 TPS on a modern 8 core system.  That's less 
than 1/4 what that server is capable of, and this patch allows working 
around that issue nicely.  pgbench not scaling up really a much worse 
problem than my test results suggest.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD