Re: [HACKERS] pgbench internal contention

2011-08-12 Thread Bruce Momjian
Robert Haas wrote: Works for me. Just to confirm, that means we'd also change GEQO to use pg_erand48(). BTW, as far as the original plan of using random_r is concerned, how did you manage to not run into this? http://sourceware.org/bugzilla/show_bug.cgi?id=3662 I just wasted half an

Re: [HACKERS] pgbench internal contention

2011-08-03 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Tue, Aug 2, 2011 at 8:44 PM, Tom Lane t...@sss.pgh.pa.us wrote: Maybe.  But if that's the approach we want to use, let's just call it pg_erand48 in the code, and dispense with the alias macros as well as all vestiges of configure support. Works

Re: [HACKERS] pgbench internal contention

2011-08-02 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: If you want erand48_r, best to provide that API, not kluge up some other functions. ...because erand48() is a GNU extension with a stupid API. I assume you mean erand48_r, there, because erand48 is pretty standard. I don't see much value in

Re: [HACKERS] pgbench internal contention

2011-08-02 Thread Robert Haas
On Tue, Aug 2, 2011 at 8:44 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: If you want erand48_r, best to provide that API, not kluge up some other functions. ...because erand48() is a GNU extension with a stupid API. I assume you mean erand48_r, there,

Re: [HACKERS] pgbench internal contention

2011-08-01 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: 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

Re: [HACKERS] pgbench internal contention

2011-08-01 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: 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

Re: [HACKERS] pgbench internal contention

2011-08-01 Thread Greg Smith
On 07/30/2011 09:08 AM, Robert Haas 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

Re: [HACKERS] pgbench internal contention

2011-08-01 Thread Robert Haas
On Mon, Aug 1, 2011 at 11:33 AM, Tom Lane t...@sss.pgh.pa.us wrote: Attached is a try at that approach. I don't find this to be a particularly safe idea:  #ifndef HAVE_ERAND48 -/* we assume all of these are present or missing together */ -extern double erand48(unsigned short xseed[3]);

Re: [HACKERS] pgbench internal contention

2011-07-30 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Fri, Jul 29, 2011 at 5:25 PM, Tom Lane t...@sss.pgh.pa.us wrote: 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

Re: [HACKERS] pgbench internal contention

2011-07-30 Thread Robert Haas
On Sat, Jul 30, 2011 at 2:32 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jul 29, 2011 at 5:25 PM, Tom Lane t...@sss.pgh.pa.us wrote: Portability, or rather lack of it.  What about using erand48, which we already have a dependency on (and substitute

Re: [HACKERS] pgbench internal contention

2011-07-30 Thread Andy Colson
On 07/29/2011 04:00 PM, Robert Haas wrote: 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(), which glibc implements like this: long int __random () { int32_t retval; __libc_lock_lock (lock);

Re: [HACKERS] pgbench internal contention

2011-07-30 Thread Robert Haas
On Jul 30, 2011, at 9:40 AM, Andy Colson a...@squeakycode.net wrote: On 07/29/2011 04:00 PM, Robert Haas wrote: 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(), which glibc implements like this:

Re: [HACKERS] pgbench internal contention

2011-07-30 Thread Robert Haas
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

[HACKERS] pgbench internal contention

2011-07-29 Thread Robert Haas
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(), which glibc implements like this: long int __random () { int32_t retval; __libc_lock_lock (lock); (void) __random_r (unsafe_state, retval);

Re: [HACKERS] pgbench internal contention

2011-07-29 Thread Tom Lane
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

Re: [HACKERS] pgbench internal contention

2011-07-29 Thread Robert Haas
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