From: | "Axel Waggershauser" <awagger(at)web(dot)de> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Low throughput of binary inserts from windows to linux |
Date: | 2006-12-12 10:18:58 |
Message-ID: | 5e66c6e90612120218p435bc0a6i80f1158fae970b9a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 12/12/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Axel Waggershauser" <awagger(at)web(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Guido Neitzer | 2006-12-12 10:34:10 | Re: New to PostgreSQL, performance considerations |
Previous Message | Daniel van Ham Colchete | 2006-12-12 09:10:34 | Re: New to PostgreSQL, performance considerations |