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