Re: pgbench internal contention

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: pgbench internal contention
Дата
Msg-id 4E3751BF.5080502@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: pgbench internal contention  (Robert Haas <robertmhaas@gmail.com>)
Список 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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: libedit memory stomp is apparently fixed in OS X Lion
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [RFC] Common object property boards