On Sat, Jul 30, 2011 at 9:08 AM, Robert Haas <robertmh...@gmail.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
pgbench-erand48.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
