Re: pgbench bug / limitation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, David Rowley <dgrowleyml(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, "Jawarilal, Manish" <Manish(dot)Jawarilal(at)dell(dot)com>
Subject: Re: pgbench bug / limitation
Date: 2020-06-05 18:10:52
Message-ID: 1510961.1591380652@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andres Freund <andres(at)anarazel(dot)de> writes:
> I'm fairly sure one can easily scale to large numbers of sockets on
> windows by using completion based APIs, but that doesn't seem like a
> realistic thing to use for pgbench anytime soon.

Agreed. Seems like the best answer is to get in bed with the Windows
representation of fd_set, since we cannot avoid knowing that it is
different from other platforms' versions. I suggest that we might as
well get all the way in and dodge the FD_SETSIZE limitation altogether,
as per the attached utterly-untested draft patch.

A remaining problem with this is that in theory, repeatedly applying
socket_has_input() after the wait could also be O(N^2) (unless FD_ISSET
is way smarter than I suspect it is). In practice, that's probably not
a huge problem since there would normally be only a few FDs in the
result fd_set. Still, I'd rather see us get out from under select()
altogether on Windows ... but maybe they *don't* have a better API
anywhere. In any case, this should be a good bit better than what we
have now.

regards, tom lane

Attachment Content-Type Size
make-pgbench-understand-windows-fd_set-1.patch text/x-diff 2.4 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Fabien COELHO 2020-06-05 18:17:01 Re: pgbench bug / limitation
Previous Message Andres Freund 2020-06-05 17:44:18 Re: pgbench bug / limitation