Re: pgbench internal contention - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgbench internal contention
Date
Msg-id 3243.1311974754@sss.pgh.pa.us
Whole thread Raw
In response to pgbench internal contention  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgbench internal contention
List pgsql-hackers
Robert Haas <robertmhaas@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)?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: pgbench internal contention
Next
From: daveg
Date:
Subject: Re: error: could not find pg_class tuple for index 2662