| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| 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 14:04:09 |
| Message-ID: | CA+TgmoZAuB+ZfMhS-LSjqsyv=gA7kBjADWf_A34cUeVTrNUmVA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Mar 15, 2015 at 3:35 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>> Firstly, the fact that pgbench produces one file per thread is awkward.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kouhei Kaigai | 2015-03-17 14:11:49 | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) |
| Previous Message | Robert Haas | 2015-03-17 13:48:23 | Re: assessing parallel-safety |