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
|
Список | 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 по дате отправления: