Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 3B32D6337D0 for ; Mon, 16 Mar 2009 12:08:37 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 50671-10 for ; Mon, 16 Mar 2009 12:08:29 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by mail.postgresql.org (Postfix) with SMTP id AB8D26324D2 for ; Mon, 16 Mar 2009 12:08:27 -0300 (ADT) Received: from source ([64.233.182.191]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSb5rahKdTgDQxOMHPytamGH4tLrrhjNK@postini.com; Mon, 16 Mar 2009 08:08:28 PDT Received: by nf-out-0910.google.com with SMTP id k4so993121nfd.2 for ; Mon, 16 Mar 2009 08:08:25 -0700 (PDT) Received: by 10.220.73.66 with SMTP id p2mr1405551vcj.109.1237216105157; Mon, 16 Mar 2009 08:08:25 -0700 (PDT) Received: from oxford.xeocode.com.enterprisedb.com ([82.16.16.210]) by mx.google.com with ESMTPS id 5sm5273ywd.19.2009.03.16.08.08.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Mar 2009 08:08:17 -0700 (PDT) To: "Jignesh K. Shah" Cc: decibel , "pgsql-performance\@postgresql.org" Subject: Re: Proposal of tunable fix for scalability of 8.4 In-Reply-To: <49BD6840.4000403@sun.com> (Jignesh K. Shah's message of "Sun\, 15 Mar 2009 16\:42\:40 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:PG" 113141) References: <49BA53CF.4020702@sun.com> <49BA742D.3050203@sun.com> <49BA8CF6.6090604@sun.com> <49BABBCE.8090501@sun.com> <49BD6840.4000403@sun.com> From: Gregory Stark Organization: EnterpriseDB Date: Mon, 16 Mar 2009 15:08:12 +0000 Message-ID: <87fxhd33qb.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200903/206 X-Sequence-Number: 33128 "Jignesh K. Shah" writes: > Generally when there is dead constant.. signs of classic bottleneck ;-) We > will be fixing one to get to another.. but knocking bottlenecks is the name of > the game I think Indeed. I think the bottleneck we're interested in addressing here is why you say you weren't able to saturate the 64 threads with 64 processes when they're all RAM-resident.