X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 8E70711F670E for ; Wed, 5 Apr 2006 20:04:06 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 49156-09 for ; Wed, 5 Apr 2006 20:04:05 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id DF5A011F6709 for ; Wed, 5 Apr 2006 20:04:03 -0300 (ADT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 9313A30D28; Thu, 6 Apr 2006 01:04:03 +0200 (MET DST) From: Chris Browne X-Newsgroups: pgsql.performance Subject: Re: Sun Fire T2000 and PostgreSQL 8.1.3 Date: Wed, 05 Apr 2006 18:11:54 -0400 Organization: cbbrowne Computing Inc Lines: 21 Message-ID: <60k6a3n045.fsf@dba2.int.libertyrms.com> References: <7583B3F1891CC0429FA4A44952AA539C66FA6D@wfm-exchprd2.wfm.pvt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.hub.org User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (linux) Cancel-Lock: sha1:X8I+/bsBqsj891Jej8LqXjM33I0= To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.306 required=5 tests=[AWL=0.306] X-Spam-Score: 0.306 X-Spam-Level: X-Archive-Number: 200604/76 X-Sequence-Number: 18160 Juan.Casero@wholefoods.com ("Juan Casero \(FL FLC\)") writes: > I am not sure about this. I mean I have postgresql 8.1.3 running on > my Windows XP P4 HT laptop that I use for testing my webapps. When > I hit this pgsql on this laptop with a large query I can see the > load spike up really high on both of my virtual processors. > Whatever, pgsql is doing it looks like both cpu's are being used > indepently. The usage curve is not identical on both of them that > makes me think that parts of the server are multithreaded. This is almost certainly a function of the fact that you're running the single-threaded backend process, which then feeds a single-threaded front end process, namely the application that is being fed data. For a query that returns a large return set, that will indeed make both processors get pretty busy; one for the DB server, one for whatever program is processing the results. -- select 'cbbrowne' || '@' || 'acm.org'; http://www.ntlug.org/~cbbrowne/rdbms.html It's hard to tell if someone is inconspicuous.