| 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: | Whole Thread | Raw Message | 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 |
| 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 |