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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
