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 E46AF9FB1F1 for ; Tue, 2 May 2006 17:29:28 -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 69092-08 for ; Tue, 2 May 2006 17:28:55 -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 D03D09FB1D3 for ; Tue, 2 May 2006 17:28:54 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 6E3B756435; Tue, 2 May 2006 15:28:38 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Tue, 2 May 2006 15:28:37 -0500 Date: Tue, 2 May 2006 15:28:37 -0500 From: "Jim C. Nasby" To: Mark Kirkwood Cc: Gregory Stewart , pgsql-performance@postgresql.org Subject: Re: Performance Issues on Opteron Dual Core Message-ID: <20060502202837.GC97354@pervasive.com> References: <445498AC.10700@paradise.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <445498AC.10700@paradise.net.nz> 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:markir@paradise.net.nz::hvi6jGB4lVvUc8Qb:000000000000000 00000000000000000000000002BC X-Hashcash: 1:20:060502:gstewart@sweetdata.com::P+Of/v5jCwM+HKUT:000000000000000 0000000000000000000000001m6a X-Hashcash: 1:20:060502:pgsql-performance@postgresql.org::MCqh7NFgx6tfDBwE:00000 0000000000000000000000001Jnj X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/45 X-Sequence-Number: 18832 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. -- 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