Re: PATCH: pgbench - merging transaction logs

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: PATCH: pgbench - merging transaction logs
Дата
Msg-id alpine.DEB.2.10.1503171614580.31431@sto
обсуждение исходный текст
Ответ на Re: PATCH: pgbench - merging transaction logs  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: PATCH: pgbench - merging transaction logs  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hello,

>> I agree, but I think it is due to the multi process thread emulation: if you
>> have real threads, you can do a simple fprintf, possibly with some mutex,
>> and you're done. There is really nothing to do to implement this
>> feature.
>
> I think that's probably not a good idea, because fprintf() might then
> become a bottleneck.  I fixed a similar problem with random() in
> commit 4af43ee3f165c8e4b332a7e680a44f4b7ba2d3c1.  Even though the
> locking was happening inside libc, it was still locking, and it still
> caused a contention problem.

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.

So I would have thought that the risk of contention because of such a lock 
would be very low in this case. If it really becomes a bottleneck, it 
means a lot of threads doing a lot of small transactions, and I would 
suggest that using the aggregated option would be the right answer to 
that.

-- 
Fabien.



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Future directions for inheritance-hierarchy statistics
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)