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

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