On Fri, Jul 29, 2011 at 5:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On machines with lots of CPU cores, pgbench can start eating up a lot >> of system time. Investigation reveals that the problem is with >> random(), > > Interesting. > >> I patched it to use random_r() - the patch is attached - and here are >> the (rather gratifying) results of that test: >> Since a client-limited benchmark isn't very interesting, I think this >> change makes sense. Thoughts? Objections? > > Portability, or rather lack of it. What about using erand48, which we > already have a dependency on (and substitute code for)?
Neither our implementation nor glibc's appears to be thread-safe, and erand48() is deprecated according to my Linux man page: NOTES These functions are declared obsolete by SVID 3, which states that rand(3) should be used instead. glibc provides erand48_r(), and I suppose we could kludge up something similar out of what's already in src/port? This is also not exactly the world's most sophisticated algorithm, but perhaps for pgbench that doesn't matter. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers