Skip site navigation (1) Skip section navigation (2)

Re: pgbench internal contention

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench internal contention
Date: 2011-08-02 01:24:15
Message-ID: 4E3751BF.5080502@2ndQuadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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 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.
>    

By the way:  the landmines in this whole area are what sunk the attempt 
to switch pgbench over to using 64 bits for the accounts table back in 
February.  See the last few messages of 
http://postgresql.1045698.n5.nabble.com/Re-PERFORM-pgbench-to-the-MAXINT-td3337374.html 
to revisit.  I think you've retraced all of that now, but double 
checking your plan against things like the AIX specific weirdness I 
pointed out there may be useful.

-- 
Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us


In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-08-02 02:19:51
Subject: Re: [RFC] Common object property boards
Previous:From: David FetterDate: 2011-08-01 20:50:15
Subject: Re: libedit memory stomp is apparently fixed in OS X Lion

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group