> 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)
(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 is
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. th
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 probl
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 networkin
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
> 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
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 remo
> 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,
> Pa
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: stat
> 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
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 (th
12 matches
Mail list logo
