Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 8BDBA683A6E for ; Fri, 11 Jun 2010 09:44:34 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 46129-05-2 for ; Fri, 11 Jun 2010 12:44:25 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by mail.postgresql.org (Postfix) with ESMTP id 615D763347F for ; Fri, 11 Jun 2010 09:44:27 -0300 (ADT) Received: from mh3.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh3.mail.rice.edu (Postfix) with ESMTP id 3FE9D324033; Fri, 11 Jun 2010 07:44:25 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.0 at mh3.mail.rice.edu Received: from mh3.mail.rice.edu ([127.0.0.1]) by mh3.mail.rice.edu (mh3.mail.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFTQHPl1jbvM; Fri, 11 Jun 2010 07:44:25 -0500 (CDT) Received: from aart.is.rice.edu (aart.is.rice.edu [168.7.56.48]) by mh3.mail.rice.edu (Postfix) with ESMTP id 04AFD32400F; Fri, 11 Jun 2010 07:44:25 -0500 (CDT) Received: by aart.is.rice.edu (Postfix, from userid 18612) id DF5862D5A6; Fri, 11 Jun 2010 07:44:24 -0500 (CDT) Date: Fri, 11 Jun 2010 07:44:24 -0500 From: Kenneth Marshall To: Anj Adu Cc: Robert Haas , Tom Lane , Andy Colson , pgsql-performance@postgresql.org Subject: Re: slow query performance Message-ID: <20100611124424.GO3063@aart.is.rice.edu> References: <4C07F7C9.3060401@squeakycode.net> <5860.1276138520@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-4.21 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201006/206 X-Sequence-Number: 39062 Hi Anj, That is an indication that your system was less correctly modeled with a random_page_cost=2 which means that the system will assume that random I/O is cheaper than it is and will choose plans based on that model. If this is not the case, the plan chosen will almost certainly be slower for any non-trivial query. You can put a 200mph speedometer in a VW bug but it will never go 200mph. Regards, Ken On Thu, Jun 10, 2010 at 07:54:01PM -0700, Anj Adu wrote: > I changed random_page_cost=4 (earlier 2) and the performance issue is gone > > I am not clear why a page_cost of 2 on really fast disks would perform badly. > > Thank you for all your help and time. > > On Thu, Jun 10, 2010 at 8:32 AM, Anj Adu wrote: > > Attached > > > > Thank you > > > > > > On Thu, Jun 10, 2010 at 6:28 AM, Robert Haas wrote: > >> On Wed, Jun 9, 2010 at 11:17 PM, Anj Adu wrote: > >>> The plan is unaltered . There is a separate index on theDate as well > >>> as one on node_id > >>> > >>> I have not specifically disabled sequential scans. > >> > >> Please do "SHOW ALL" and attach the results as a text file. > >> > >>> This query performs much better on 8.1.9 on a similar sized > >>> table.(althought the random_page_cost=4 on 8.1.9 and 2 on 8.4.0 ) > >> > >> Well that could certainly matter... > >> > >> -- > >> Robert Haas > >> EnterpriseDB: http://www.enterprisedb.com > >> The Enterprise Postgres Company > >> > > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance >