Horton

Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Rady, Doug" <radydoug@amazon.com>, Fabien COELHO <coelho@cri.ensmp.fr>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2018-04-06T21:54:14Z
Lists: pgsql-hackers 
On 2018-04-06 17:49:19 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.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.

It's not that crazy to use more than 1024 connections (common FD_SETSIZE
valu), especially over a higher latency connection.

As I wrote, I think using a poll API that doesn't require looping over
all sockets, even if they didn't get an event, would be a better plan.

- Andres

Commits

  1. Use ppoll(2), if available, to wait for input in pgbench.

  2. Use pselect(2) not select(2), if available, to wait in postmaster's loop.