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@bfk.de]
Sent: 2006Ae7OA20EO 0:18
To: Guoping Zhang
Cc: pgsql-performance@postgresql.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@bfk.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
