Re: PATCH: pgbench - merging transaction logs

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: PATCH: pgbench - merging transaction logs
Дата
Msg-id 20150321100422.GB3075@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: PATCH: pgbench - merging transaction logs  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: PATCH: pgbench - merging transaction logs  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
On 2015-03-17 11:50:28 -0400, Robert Haas wrote:
> On Tue, Mar 17, 2015 at 11:27 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
> > The fprintf we are talking about occurs at most once per pgbench
> > transaction, possibly much less when aggregation is activated, and this
> > transaction involves networks exchanges and possibly disk writes on the
> > server.
> 
> random() was occurring four times per transaction rather than once,
> but OTOH I think fprintf() is probably a much heavier-weight
> operation.  The way to know if there's a real problem here is to test
> it, but I'd be pretty surprised if there isn't.

Well, fprintf() doesn't have to acquire the lock for the entirety of
it's operation - just for the access to the stream buffer.

Note that posix 2001 *does* guarantee that FILE* style IO is thread
safe:
"All functions that reference (FILE *) objects, except those with names
ending in _unlocked, shall behave as if they use flockfile() and
funlockfile() internally to obtain ownership of these (FILE *) objects."

Hilariously that tidbit hidden in the documentation about
flockfile. Very, err, easy to find:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/flockfile.html

But I agree that we simply need to test this on a larger machine.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: PATCH: pgbench - merging transaction logs
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: GIN code managing entry insertion not able to differentiate fresh and old indexes