Re: PATCH: pgbench - merging transaction logs - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: PATCH: pgbench - merging transaction logs
Date
Msg-id alpine.DEB.2.10.1503171614580.31431@sto
Whole thread Raw
In response to Re: PATCH: pgbench - merging transaction logs  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: PATCH: pgbench - merging transaction logs
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Future directions for inheritance-hierarchy statistics
Next
From: Tom Lane
Date:
Subject: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)