Guoping Zhang wrote:
a) SERVER A to SERVER B: 0.35ms
SERVER A to itself (Local host): 0.022ms
0.35ms seems rather slow. You might try investigating what's in the path.
For comparison, between two machines here (three GigE switches in the
path), I see 0.10ms RTT. Between two machines on
't try now.
Thanks for all the answers...
Regards,
Guoping Zhang
-Original Message-
From: Florian Weimer [mailto:[EMAIL PROTECTED]
Sent: 2006Ae7OA20EO 0:18
To: Guoping Zhang
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Performance penalty for remote access of
postgres
Stephen Frost wrote:
* Guoping Zhang ([EMAIL PROTECTED]) wrote:
Obviously, if there is no better solution, the TCP round trip penalty will
stop us doing so as we do have performance requirement.
Actually, can't you stick multiple inserts into a given 'statement'?
ie: insert into abc (123); in
In response to "Guoping Zhang" <[EMAIL PROTECTED]>:
>
> Thanks for pointing me the cause, but we simply cannot use the COPY FROM
> solution.
>
> Currently, our application service is running with its own dedicated local
> database, IF Feasible, we want to separate the application services out of
* Florian Weimer ([EMAIL PROTECTED]) wrote:
> * 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 nowa
* 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<[EMAIL PROTEC
* Guoping Zhang ([EMAIL PROTECTED]) wrote:
> Obviously, if there is no better solution, the TCP round trip penalty will
> stop us doing so as we do have performance requirement.
Actually, can't you stick multiple inserts into a given 'statement'?
ie: insert into abc (123); insert into abc (234);
* Guoping Zhang:
> Thanks for pointing me the cause, but we simply cannot use the COPY FROM
> solution.
Why not? Just do something like this:
CREATE TEMPORARY TABLE tmp (col1 TEXT NOT NULL, col2 INTEGER NOT NULL);
COPY tmp FROM STDIN;
row11
row22
...
\.
INSERT INTO target SELECT * FROM
: [EMAIL PROTECTED]
Cc: pgsql-performance@postgresql.org; Guoping Zhang (E-mail)
Subject: Re: [PERFORM] Performance penalty for remote access of
postgresql (8.1.3)? any experiance?
* Guoping Zhang:
> a) Anyone has the similar experience? How do you deal with it?
> b) Why TCP stack imposes su
* Guoping Zhang:
> a) Anyone has the similar experience? How do you deal with it?
> b) Why TCP stack imposes such big delay? any tuning point I shall do?
If you use INSERT, you'll incur a network round-trip delay for each
record. Try using COPY FROM instead, possibly to a temporary table if
Hello,
I am seeking advice/comment/experience you may have had for the performance
cost for remote access to postgresql 8.1.X?
I have two servers, one is Sun V240 (say server A) and the other is dual
intel Xeon (say Server B) and both installed Solaris 10.
With Server A, there is postgresql 8.1
11 matches
Mail list logo
