Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 101772A7FAD for ; Mon, 30 Jan 2012 17:25:19 -0400 (AST) Received: from smtp.01.com ([199.36.142.181]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Rryj1-0007uM-HH for pgsql-performance@postgresql.org; Mon, 30 Jan 2012 21:25:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id F0BB94F4AA4 for ; Mon, 30 Jan 2012 15:25:06 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My1D8rWJx5ya for ; Mon, 30 Jan 2012 15:25:06 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id D06894F4A83 for ; Mon, 30 Jan 2012 15:25:06 -0600 (CST) Received: from Sidney-Stratton.local (unknown [12.154.42.75]) by smtp-out-2.01.com (Postfix) with ESMTPSA id 74D964F464E for ; Mon, 30 Jan 2012 15:25:06 -0600 (CST) Message-ID: <4F270AB1.6070100@agliodbs.com> Date: Mon, 30 Jan 2012 13:25:05 -0800 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.24) Gecko/20111103 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Why should such a simple query over indexed columns be so slow? References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201201/133 X-Sequence-Number: 46145 On 1/30/12 12:59 PM, Claudio Freire wrote: > On Mon, Jan 30, 2012 at 5:55 PM, Alessandro Gagliardi > wrote: >> Hm. Well, it looks like setting enable_seqscan=false is session specific, so >> it seems like I can use it with this query alone; but it sounds like even if >> that works, it's a bad practice. (Is that true?) > > Yep The issue with that is that the enable_seqscan setting is not limited to that one table in that query, and won't change over time. So by all means use it as a hotfix right now, but it's not a long-term solution to your problem. > >> My effective_cache_size is 1530000kB That seems appropriate for the Ronin; I'll test one out and see what random_page_cost is set to as well, possibly Heroku needs to adjust the basic template for the Ronin. For Heroku, we want to favor index scans a bit more than you would on regular hardware because the underlying storage is Amazon, which has good seeks but crap throughput. You can do "SHOW random_page_cost" yourself right now, too. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com