Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 621E49F9F08
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 12 Dec 2006 12:56:11 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024)
	with ESMTP id 49949-05 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 12 Dec 2006 12:56:01 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from skunk.mtbrook.bozemanpass.com (skunk.mtbrook.bozemanpass.com
	[69.145.82.195])
	by postgresql.org (Postfix) with ESMTP id E61D39FA0EF
	for <pgsql-performance@postgresql.org>;
	Tue, 12 Dec 2006 12:56:01 -0400 (AST)
Received: from [69.145.82.249] (unknown [69.145.82.249])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by skunk.mtbrook.bozemanpass.com (Postfix) with ESMTP id 0CD32558371;
	Tue, 12 Dec 2006 08:56:01 -0800 (PST)
Message-ID: <457EDF22.4010303@boreham.org>
Date: Tue, 12 Dec 2006 09:56:02 -0700
From: David Boreham <david_list@boreham.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Axel Waggershauser <awagger@web.de>,
 pgsql-performance@postgresql.org
Subject: Re: Low throughput of binary inserts from windows to linux
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>
	<4101.1165941200@sss.pgh.pa.us>
In-Reply-To: <4101.1165941200@sss.pgh.pa.us>
Content-Type: multipart/alternative;
	boundary="------------050502020808040508080704"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200612/302
X-Sequence-Number: 22358

This is a multi-part message in MIME format.
--------------050502020808040508080704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.






--------------050502020808040508080704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tom Lane wrote:<br>
<blockquote cite="mid4101.1165941200@sss.pgh.pa.us" type="cite">
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No, it would mean a bug in Windows in that it fails to honor TCP_NODELAY.
  </pre>
</blockquote>
Last time I did battle with nagle/delayed ack interaction in windows
(the other end<br>
has to be another stack implementation -- windows to itself I don't
think has the problem),<br>
it _did_ honor TCP_NODELAY. That was a while ago (1997) but I'd be
surprised<br>
if things have changed much since then.<br>
<br>
Basically nagle has to be turned off for protocols like this
(request/response interaction<br>
over TCP) otherwise you'll sometimes end up with stalls waiting for the
delayed ack<br>
before sending, which in turn results in very low throughput, per
connection. As I remember<br>
Windows client talking to Solaris server had the problem, but various
other permutations<br>
of client and server stack implementation did not.<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

--------------050502020808040508080704--