Re: Low throughput of binary inserts from windows to linux
От | Axel Waggershauser |
---|---|
Тема | Re: Low throughput of binary inserts from windows to linux |
Дата | |
Msg-id | 5e66c6e90612120218p435bc0a6i80f1158fae970b9a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Low throughput of binary inserts from windows to linux (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Low throughput of binary inserts from windows to linux
|
Список | pgsql-performance |
On 12/12/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Axel Waggershauser" <awagger@web.de> writes: > > I tested different sizes on linux some time ago and found that 64KB > > was optimal. But playing with different sizes again revealed that my > > windows->linux problem seems to be solved if I use _any_ other > > (reasonable - meaning something between 4K and 512K) power of two ?!? > > I think this almost certainly indicates a Nagle/delayed-ACK > interaction. I googled and found a nice description of the issue: > http://www.stuartcheshire.org/papers/NagleDelayedAck/ But that means I must have misinterpreted fe-connect.c, right? Meaning on the standard windows build the setsockopt(conn->sock, IPPROTO_TCP, TCP_NODELAY, (char *) &on, sizeof(on)) line gets never called (eather because TCP_NODELAY is not defined or IS_AF_UNIX(addr_cur->ai_family) in PQconnectPoll evaluates to true). 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. Axel
В списке pgsql-performance по дате отправления: