To: "Axel Waggershauser" <awagger@web.de>
cc: pgsql-performance@postgresql.org
Subject: Re: Low throughput of binary inserts from windows to linux 
In-reply-to: <5e66c6e90612111444y78729a71m4ec9852ae9bc8567@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>
Comments: In-reply-to "Axel Waggershauser" <awagger@web.de>
	message dated "Mon, 11 Dec 2006 23:44:25 +0100"
Date: Mon, 11 Dec 2006 20:25:26 -0500
Message-ID: <21549.1165886726@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"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/

Note that there are no TCP connections in which message payloads are
exact powers of two (and no, I don't know why they didn't try to make
it so).  You are probably looking at a situation where this particular
transfer size results in an odd number of messages where the other sizes
do not, with the different overheads between Windows and everybody else
accounting for the fact that it's only seen with a Windows sender.

If you don't like that theory, another line of reasoning has to do with
the fact that the maximum advertiseable window size in TCP is 65535 ---
there could be some edge-case behaviors in the Windows and Linux stacks
that don't play nicely together for 64K transfer sizes.

			regards, tom lane