Tom Lane wrote:
In case I was mistaken, this explanation makes perfectly sens to me.
But then again it would indicate a 'bug' in libpq, in the sense that
it (apparently) sets TCP_NODELAY on linux but not on windows.
No, it would mean a bug in Windows in that it fails to honor TCP_NODELAY.
Last time I did battle with nagle/delayed ack interaction in windows (the other end
has to be another stack implementation -- windows to itself I don't think has the problem),
it _did_ honor TCP_NODELAY. That was a while ago (1997) but I'd be surprised
if things have changed much since then.
Basically nagle has to be turned off for protocols like this (request/response interaction
over TCP) otherwise you'll sometimes end up with stalls waiting for the delayed ack
before sending, which in turn results in very low throughput, per connection. As I remember
Windows client talking to Solaris server had the problem, but various other permutations
of client and server stack implementation did not.