Re: TCP network cost

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: TCP network cost
Date: 2009-02-18 13:44:23
Message-ID: 87hc2r272g.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Ross J. Reedstrom" <reedstrm(at)rice(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Grzegorz Jaśkiewicz 2009-02-18 14:05:40 Re: suggestions for postgresql setup on Dell 2950 , PERC6i controller
Previous Message Alexander Gorban 2009-02-18 10:24:07 Re: Call of function inside trigger much slower than explicit function call