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 90FE111F6706 for ; Wed, 5 Apr 2006 19:24:58 -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 74697-09 for ; Wed, 5 Apr 2006 19:24:57 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id CC2AF11F66FE for ; Wed, 5 Apr 2006 19:24:54 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k35MOlx7012746; Wed, 5 Apr 2006 18:24:47 -0400 (EDT) To: josh@agliodbs.com cc: pgsql-performance@postgresql.org, "Juan Casero \(FL FLC\)" , "Luke Lonergan" Subject: Re: Sun Fire T2000 and PostgreSQL 8.1.3 In-reply-to: <200604051501.40109.josh@agliodbs.com> References: <7583B3F1891CC0429FA4A44952AA539C66FA6D@wfm-exchprd2.wfm.pvt> <200604051501.40109.josh@agliodbs.com> Comments: In-reply-to Josh Berkus message dated "Wed, 05 Apr 2006 15:01:39 -0700" Date: Wed, 05 Apr 2006 18:24:47 -0400 Message-ID: <12745.1144275887@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.114 required=5 tests=[AWL=0.114] X-Spam-Score: 0.114 X-Spam-Level: X-Archive-Number: 200604/75 X-Sequence-Number: 18159 Josh Berkus writes: > Juan, >> 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. > Nope, sorry, you're being decieved. Postgres is strictly one process, one > query. This is not strictly true: we have for instance pushed off some work into a "background writer" process, and even just having both a client and a server process active allows some small amount of parallelism. But you're certainly not going to see effective use of more than about two CPUs on a single query stream ... at least not without Bizgres or some other add-on. regards, tom lane