Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 12BD29F946C for ; Tue, 12 Dec 2006 12:33:42 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 35162-08 for ; Tue, 12 Dec 2006 12:33:22 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id D398F9F931E for ; Tue, 12 Dec 2006 12:33:21 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id kBCGXKUE004102; Tue, 12 Dec 2006 11:33:20 -0500 (EST) To: "Axel Waggershauser" cc: pgsql-performance@postgresql.org Subject: Re: Low throughput of binary inserts from windows to linux In-reply-to: <5e66c6e90612120218p435bc0a6i80f1158fae970b9a@mail.gmail.com> References: <5e66c6e90612080417r23ecaea4p210905f868c26c7f@mail.gmail.com> <5e66c6e90612081724m57293ffdy21d6b45697e69bd4@mail.gmail.com> <3317.1165636358@sss.pgh.pa.us> <5e66c6e90612110658r3c0918f6v4fd3682363db5c15@mail.gmail.com> <12645.1165852740@sss.pgh.pa.us> <5e66c6e90612111444y78729a71m4ec9852ae9bc8567@mail.gmail.com> <21549.1165886726@sss.pgh.pa.us> <5e66c6e90612120218p435bc0a6i80f1158fae970b9a@mail.gmail.com> Comments: In-reply-to "Axel Waggershauser" message dated "Tue, 12 Dec 2006 11:18:58 +0100" Date: Tue, 12 Dec 2006 11:33:20 -0500 Message-ID: <4101.1165941200@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/300 X-Sequence-Number: 22356 "Axel Waggershauser" writes: > On 12/12/06, Tom Lane wrote: >> 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/ > 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. Again, given that you only see the behavior at one specific message length, I suspect this is a corner case rather than a generic "it doesn't work" issue. We're pretty much guessing though. Have you tried tracing the traffic with a packet sniffer to see what's really happening at different message sizes? regards, tom lane