Re: SO_SNDBUF size is small on win32?

> > From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

For once, I beleive you are :-)
We use non-blocking sockets in backend/port/win32/socket.c so we are
able to deliver our "faked signals" while waiting for I/O on the socket.
We specifically set it in pgwin32_socket().

Given that, it might be a good idea to actually put the code there
instead, to localise it. With a comment and a reference to that Q
article.

> 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.

We have definitly seen weird timing issues sometimes when both client
and server were on Windows, but have been unable to pin it exactly on
what. From Yoshiykis other mail it looks like this could possibly be it,
since he did experience a speedup in the range we've been looking for in
those cases.

> 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...

It could definitly be a good idea to have a patch there *as well*, but I
think they'd both be affected.

//Magnus