Skip site navigation (1) Skip section navigation (2)

Re: Performance penalty for remote access of postgresql (8.1.3)? any experiance?

From: "Guoping Zhang" <guoping(dot)zhang(at)nec(dot)com(dot)au>
To: "'Florian Weimer'" <fweimer(at)bfk(dot)de>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Performance penalty for remote access of postgresql (8.1.3)? any experiance?
Date: 2006-07-20 06:32:45
Message-ID: 003d01c6abc6$5039aff0$74304c93@eddy (view raw or flat)
Thread:
Lists: pgsql-performance
Thanks for all the replies from different ppl.

As you pointed out, each INSERT/UPDATE operation will result in a TCP
round-trip delay for postgresql (may well true for all DBMS), this is the
big problem to challenge our requirements, as extensively modify the
(legacy) applicatioin is not a preferable choice.

I measured the round-trip (UDP) delay as below:

a)  SERVER A to SERVER B: 0.35ms
    SERVER A to itself (Local host): 0.022ms

That is, in the tests I did yesterday, it is about 100k insert operations,
which means added around 35 seconds of delay.....

b) Also, using Iperf shows that
    TCP bandwidth between Server A and B is about 92.3 Mbits/sec
    TCP bandwidth between two ports at same Server A can reach 10.9Gbits/sec

That indicates the performance impact for the networking....

There might be parameter in Solaris to tune the 'ack response delay', but I
didn't try now.

Thanks for all the answers...

Regards,
Guoping Zhang



-----Original Message-----
From: Florian Weimer [mailto:fweimer(at)bfk(dot)de]
Sent: 2006Ae7OA20EO 0:18
To: Guoping Zhang
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Performance penalty for remote access of
postgresql (8.1.3)? any experiance?


* Stephen Frost:

> Actually, can't you stick multiple inserts into a given 'statement'?
> ie: insert into abc (123); insert into abc (234);

IIRC, this breaks with PQexecParams, which is the recommended method
for executing SQL statements nowadays.

--
Florian Weimer                <fweimer(at)bfk(dot)de>
BFK edv-consulting GmbH       http://www.bfk.de/
Durlacher Allee 47            tel: +49-721-96201-1
D-76131 Karlsruhe             fax: +49-721-96201-99


In response to

Responses

pgsql-performance by date

Next:From: David BorehamDate: 2006-07-20 13:54:58
Subject: Re: Performance penalty for remote access of postgresql
Previous:From: Joe ConwayDate: 2006-07-19 15:49:17
Subject: Re: Performance penalty for remote access of postgresql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group