Re: Low throughput of binary inserts from windows to linux
От | David Boreham |
---|---|
Тема | Re: Low throughput of binary inserts from windows to linux |
Дата | |
Msg-id | 457EDF22.4010303@boreham.org обсуждение исходный текст |
Ответ на | Re: Low throughput of binary inserts from windows to linux (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Tom Lane wrote:
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.
Last time I did battle with nagle/delayed ack interaction in windows (the other endIn 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.
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.
В списке pgsql-performance по дате отправления: