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

From: "Rady, Doug" <radydoug(at)amazon(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: "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-01-28 23:02:57
Message-ID: 654A1247-8E1E-4E9C-937D-9119B1731FF2@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/26/18, 15:00, "Fabien COELHO" <coelho(at)cri(dot)ensmp(dot)fr> wrote:
Hello Doug,

Hello Fabien,

Patch applies, compiles, tests ok.

> > [...] Replaced USE_PPOLL with HAVE_PPOLL as having both seems redundant.
>
> I'm okay with that. I'm wondering whether there should be a way to force
> using one or the other when both are available. Not sure.
>
> Added option to force use of select(2) via: -DUSE_SELECT

USE_SELECT could mean something somewhere. Maybe use something more
specific like PGBENCH_USE_SELECT? Having this macro available simplifies
testing.

Changed to PGBENCH_USE_SELECT

I'm not sure why you do the following trick, could you explain?
+#undef USE_SELECT
+#define USE_SELECT

This was due to compiler complaint about USE_SELECT being redefined.
Have replaced that "trick" with a new #define POLL_USING_SELECT which is used elsewhere in pgbench instead.

In the select implementation you do:

return (socket_set *) pg_malloc0(sizeof(socket_set) * MAXCLIENTS);

but ISTM that socket_set is already an fd_set which represents a set of
clients, so allocating a number of it is needed. The initial
implementation just does "fs_set input_mask", whetever the number of
clients, and it works fine.

Ugh. Yes, for socket() only one (1) fd_set is needed.
Fixed.

--
Fabien.

Thank you, again!!
doug

Attachment Content-Type Size
pgbench11-ppoll-v10.patch application/octet-stream 10.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ivan Novick 2018-01-28 23:11:25 Re: Built-in connection pooling
Previous Message Thomas Munro 2018-01-28 23:02:51 Re: Documentation of pgcrypto AES key sizes