Yoshiyuki Asaba <y-asaba@sraoss.co.jp> writes:
> From: Tom Lane <tgl@sss.pgh.pa.us>
>> It also says that the condition only occurs if the program uses
>> non-blocking sockets ... which the backend does not. So this page
>> offers no support for the proposed patch.
> WSAEventSelect() sets a socket to nonblocking mode.
Yeah, but that socket is only used for inter-backend signaling with
small (1 byte, I think) messages. The socket used for communication
with the frontend is not in nonblocking mode, unless I'm totally
confused.
Have you actually measured any performance benefit from this patch,
and if so what was the test case? I'm not opposed to the patch if it
does something useful, but the info currently available does not suggest
that it will help.
What I would think might help is a patch on the libpq side (because it
*does* use a nonblocking socket) to avoid sending more than 8K per
WSASend call. The effect would just be to break a long send into a
series of shorter sends, which wouldn't really do anything useful on a
well-designed TCP stack, but then this is Windows we're talking about...
regards, tom lane
