| From: | konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, "Rady, Doug" <radydoug(at)amazon(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: PATCH: pgbench - option to build using ppoll() for larger connection counts |
| Date: | 2018-04-07 05:20:35 |
| Message-ID: | 7931C1C9-BA15-435C-B350-630F766A01B2@postgrespro.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Apr 7, 2018, at 12:49 AM, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> I'm still not particularly happy with this.
>
> I'm a bit confused as to what the point is. It seems unlikely that one
> pgbench process can effectively drive enough backends for select's
> limitations to really be an issue.
pgbench is multithreaded application, so in theory it can drive almost arbitrary number of connections.
It is limited only by network throughput, but if pgbench is launched at the same host and connected to the server through loopback or unix sockets,
then network is also not a limit.
We quite often have to spawn more than 1k connections and SMP systems with hundreds of CPU.
So there are two choices: either use patched version of pgbench which is using poll, either spawn several instances of pgbench (which is not always convenient).
>
> regards, tom lane
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2018-04-07 05:49:16 | Re: [HACKERS] Runtime Partition Pruning |
| Previous Message | Andres Freund | 2018-04-07 05:01:04 | Re: [HACKERS] Runtime Partition Pruning |