Re: PATCH: pgbench - merging transaction logs

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: pgbench - merging transaction logs
Date: 2015-03-17 15:27:25
Message-ID: alpine.DEB.2.10.1503171614580.31431@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-03-17 15:32:24 Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)
Previous Message Tom Lane 2015-03-17 15:26:08 Re: Future directions for inheritance-hierarchy statistics