> 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.
As I said earlier, I would boost the socket buffer to something larger
than merely 2x the packet size. I'd try for 32K (32768), that way we have
some space for additional buffers before we hit the problem. It is
presumed that we should have enough data in the socket buffer to at least
try to match the expected amount of data that would be sent while waiting
for the defered ACK.