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@xxxxxx] Sent: 2006Ae7OA20EO 0:18 To: Guoping Zhang Cc: pgsql-performance@xxxxxxxxxxxxxx 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@xxxxxx> BFK edv-consulting GmbH http://www.bfk.de/ Durlacher Allee 47 tel: +49-721-96201-1 D-76131 Karlsruhe fax: +49-721-96201-99