Re: Performance Issues on Opteron Dual Core - Mailing list pgsql-performance

From Jan de Visser
Subject Re: Performance Issues on Opteron Dual Core
Date
Msg-id 200605021849.48613.jdevisser@digitalfairway.com
Whole thread Raw
In response to Re: Performance Issues on Opteron Dual Core  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: Performance Issues on Opteron Dual Core
List pgsql-performance
On Tuesday 02 May 2006 16:28, Jim C. Nasby wrote:
> On Sun, Apr 30, 2006 at 10:59:56PM +1200, Mark Kirkwood wrote:
> > Pgadmin can give misleading times for queries that return large result
> > sets over a network, due to:
> >
> > 1/ It takes time to format the (large) result set for display.
> > 2/ It has to count the time spent waiting for the (large) result set to
> > travel across the network.
> >
> > You aren't running Pgadmin off the dev server are you? If not check your
> > network link to dev and prod  - is one faster than the other? (etc).
> >
> > To eliminate Pgadmin and the network as factors try wrapping your query
> > in a 'SELECT count(*) FROM (your query here) AS a', and see if it
> > changes anything!
>
> FWIW, I've found problems running PostgreSQL on Windows in a multi-CPU
> environment on w2k3. It runs fine for some period, and then CPU and
> throughput drop to zero. So far I've been unable to track down any more
> information than that, other than the fact that I haven't been able to
> reproduce this on any single-CPU machines.

I have had previous correspondence about this with Magnus (search -general
and -hackers). If you uninstall SP1 the problem goes away. We played a bit
with potential fixes but didn't find any.

jan

--
--------------------------------------------------------------
Jan de Visser                     jdevisser@digitalfairway.com

                Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------

pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Slow restoration question
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Postgres 7.4 and vacuum_cost_delay.