X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 4A6B09FA2C7 for ; Tue, 2 May 2006 19:56:39 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 15016-01 for ; Tue, 2 May 2006 19:56:30 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 92F4A9FB1D5 for ; Tue, 2 May 2006 19:56:30 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 6AADC56435; Tue, 2 May 2006 17:56:29 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Tue, 2 May 2006 17:56:28 -0500 Date: Tue, 2 May 2006 17:56:28 -0500 From: "Jim C. Nasby" To: Jan de Visser Cc: pgsql-performance@postgresql.org Subject: Re: Performance Issues on Opteron Dual Core Message-ID: <20060502225628.GM97354@pervasive.com> References: <445498AC.10700@paradise.net.nz> <20060502202837.GC97354@pervasive.com> <200605021849.48613.jdevisser@digitalfairway.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605021849.48613.jdevisser@digitalfairway.com> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060502:jdevisser@digitalfairway.com::J1Qpk3fK6nbHNKVS:000000000 000000000000000000000000Ab77 X-Hashcash: 1:20:060502:pgsql-performance@postgresql.org::2l+TIYeqLASwacpR:00000 0000000000000000000000001qTS X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/57 X-Sequence-Number: 18844 On Tue, May 02, 2006 at 06:49:48PM -0400, Jan de Visser wrote: > 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. Interesting; does SP2 fix the problem? Anything we can do over here to help? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461