Re: pgbench internal contention

On Sat, Jul 30, 2011 at 9:08 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> If I'm reading the code right, it only modifies __libc_drand48_data on
> first call, so as long as we called erand48() at least once before
> spawning the child threads, it would probably work.  That seems pretty
> fragile in the face of the fact that they explicitly state that
> they're modifying the global random generator state and that you
> should use erand48_r() if you want reentrant behavior.  So I think if
> we're going to go the erand48() route we probably ought to force
> pgbench to always use our version rather than any OS-supplied version.

Attached is a try at that approach. Performance benefits are similar
to before. Same test case as in my OP on this thread, alternating
runs without and with this patch:

tps = 199133.418419 (including connections establishing)
real 5m0.017s
user 23m42.170s
sys 18m46.270s

tps = 226202.289151 (including connections establishing)
real 5m0.018s
user 22m7.520s
sys 9m54.570s

tps = 191144.247489 (including connections establishing)
real 5m0.025s
user 23m35.200s
sys 17m19.070s

tps = 226353.187955 (including connections establishing)
real 5m0.017s
user 21m42.300s
sys 10m9.820s

tps = 189602.248908 (including connections establishing)
real 5m0.044s
user 23m24.060s
sys 17m1.050s

tps = 224521.459164 (including connections establishing)
real 5m0.017s
user 22m9.620s
sys 10m22.590s

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company