To: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: TCP network cost
In-Reply-To: <20090217200416.GA23707@cooker> (Ross J. Reedstrom's message of
	"Tue\, 17 Feb 2009 14\:04\:17 -0600")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <20090217070403.GB2486@cooker>
	<1ca1c1410902171013q478f2620n13fcd68cb8b3d911@mail.gmail.com>
	<20090217070403.GB2486@cooker>
	<3FAF940B-9B0B-4DBA-8728-6096022129DF@infogears.com>
	<alpine.DEB.1.10.0902170032440.25606@asgard.lang.hm>
	<20090217070403.GB2486@cooker>
	<3FAF940B-9B0B-4DBA-8728-6096022129DF@infogears.com>
	<20090217200416.GA23707@cooker>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Wed, 18 Feb 2009 13:44:23 +0000
Message-ID: <87hc2r272g.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Ross J. Reedstrom" <reedstrm@rice.edu> writes:

> On Tue, Feb 17, 2009 at 12:20:02AM -0700, Rusty Conover wrote:
>> 
>> Try running tests with ttcp to eliminate any PostgreSQL overhead and  
>> find out the real bandwidth between the two machines.  If its results  
>> are also slow, you know the problem is TCP related and not PostgreSQL  
>> related.
>
> I did in fact run a simple netcat client/server pair and verified that I
> can transfer that file on 0.12 sec localhost (or hostname), 0.35 over the
> net, so TCP stack and network are not to blame. This is purely inside
> the postgresql code issue, I believe.

There's not much Postgres can do to mess up TCP/IP. The only things that come
to mind are a) making lots of short-lived connections and b) getting caught by
Nagle when doing lots of short operations and blocking waiting on results.

What libpq (or other interface) operations are you doing exactly?

[also, your Mail-Followup-To has a bogus email address in it. Please don't do
that]

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's On-Demand Production Tuning