On Tue, Sep 13, 2005 at 11:05:00AM -0400, Merlin Moncure wrote:
5. do select array_accum(q::text) from generate_series(1,1) q;
I made the tests you suggested and the pattern is clear. The difference
between local and remote command execution is caused by moving data over
the network. E.g.
(1) Latency and throughput don't necessarily correlate well. When blasting
quantities of data to test throughput, TCP_NODELAY might not matter
much -- a full buffer will be sent without a delay anyway. What do you get
on a ping while running the throughput test?
(2) Besides the TCP_NODELAY
in the 10 ms range. Definitely not 800 ms. The 8.1 has the same
problem.
Just for the record: the server PC is Dell Precision 330 with 3Com
3C920
integrated network card. OS MS Windows Professional 2002 with service
pack
2. There is Symantec Antivirus installed - which I have (hopefully)
Hello.
I would like to build a shared repository for Enterprise Architect
(http://www.sparxsystems.com.au/ea.htm) using PostgreSQL. I have done it
before with Linux and FreeBSD servers and everything was working out of the
box. The repository is pretty simple database with less than 100 tables
Hello.
I would like to build a shared repository for Enterprise Architect
(http://www.sparxsystems.com.au/ea.htm) using PostgreSQL. I have done
it
before with Linux and FreeBSD servers and everything was working out
of
the
box. The repository is pretty simple database with less than 100
On Tue, Sep 13, 2005 at 07:58:20AM -0400, Merlin Moncure wrote:
Can you give specific examples of cases that are not performing like you
expect? If possible, give a few queries with explain analyze times and
all that.
O.K. I have found one particular problem:
2005-09-13 14:43:02 LOG:
On Tue, Sep 13, 2005 at 07:58:20AM -0400, Merlin Moncure wrote:
This command is executed while a model is loaded from the repository.
The table definition is:
CREATE TABLE t_umlpattern (
PatternID INTEGER DEFAULT nextval('patternid_seq'::text) NOT
NULL
PRIMARY KEY,
On Tue, Sep 13, 2005 at 10:20:05AM -0400, Merlin Moncure wrote:
I loaded your dump and was able to select entire table in trivial time
from both pgAdmin and psql shell. I am suspecting some type of tcp
problem here. Can you confirm slow times on unloaded server?
Did you run the select
Did you run the select remotely on a Windows server?
yes.
Yes the server load is practically 0. Note the difference between
local
and
remote execution of the command. I think you are right about the
network
problem possibility. But it is bound to PostgreSQL. MySQL on the same
machine (and
This is sounding suspiciously similar to behavior I've seen with other types of
TCP database connections when the tcp-no-delay option is not on. Is it
possible that the ODBC driver for Windows is not successfully setting this up?
-Kevin
Dalibor Sramek [EMAIL PROTECTED] 09/13/05 9:34 AM
Dalibor Sramek [EMAIL PROTECTED] writes:
select * from t_umlpattern limit 2
takes 1500+ msec on the Windows machine and 60 on a comparable Linux
machine. Both selects performed from remote PgAdmin.
The same select performed localy on the windows machine takes 60 msec.
So it's a networking
On Tue, Sep 13, 2005 at 11:32:02AM -0400, Tom Lane wrote:
So it's a networking issue. I haven't paid real close attention to
...
updates. Check through the list archives ...
This one
http://archives.postgresql.org/pgsql-performance/2005-06/msg00593.php
seems to be very similar to my
12 matches
Mail list logo
