"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
