> > That's pretty odd. If you use \timing in psql, you can get execution
> > time for each query, if it helps you track things down.
> Yes, in the new server running with \timing it consumes 5.6 seconds
> and in the old server it consumes 25 seconds.
> > > Correct me if am I wrong but, executing PgAdmin in the same server
> there aren't networks delays!
> > Not network, no. But the results of your explains seem to show that the
> > query is executing much faster on the new system than the old, so the
> > problem still becomes, "what is happening after the query completes that
> > is so slow?" It's just that networking is ruled out.
> Is connected to full 100Mb, it transfers many things quick to clients.
> Is running Apache adn JBoss, transfer rate is good, I did scp to copy
> many archives and is as quick as the old server.
> I have no idea how to continue researching this problem. Now I'm going
> to do some networks tests.
See if this can give some help to you:
I was experienced some problems with networks with win98 and winXP
stations, the application was running with good performance almost of
but in suddenly the performance slow down. We noticed that the problem
was with the time to connect with the server, that was very slow.
The problem occurs also when the internet link down.
Well, I don't know why but when we exclude win98 stations from network,
the problem disappears.
I think that was some DNS problem (but not sure), because one time we
cleared nameserver clauses in the /etc/resolv.conf the performance
return to the normal.
But we reinstalled win98 machines with winXP too, so I don't know what
The server OS was a Mandriva Linux running postgres ( 8.0, I guess) and
samba. Workstations connect via odbc (informing the IP of server or the
name to connect the problem persists).
Luiz K. Matsumura
Plan IT Tecnologia Informática Ltda.
In response to
pgsql-performance by date
|Next:||From: Dave Dutcher||Date: 2007-09-21 20:55:36|
|Subject: Re: Low CPU Usage|
|Previous:||From: Denes Daniel||Date: 2007-09-21 20:05:29|
|Subject: Re: Query planner unaware of possibly best plan|