Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 44FBE6324AA for ; Thu, 29 Jul 2010 08:15:13 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 83034-02 for ; Thu, 29 Jul 2010 11:15:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from anastacia.gransy.com (anastacia.gransy.com [77.78.104.100]) by mail.postgresql.org (Postfix) with ESMTP id 7C350632467 for ; Thu, 29 Jul 2010 08:15:05 -0300 (ADT) Received: from sq.gransy.com (localhost [127.0.0.1]) by anastacia.gransy.com (Postfix) with ESMTP id E078EAAC130; Thu, 29 Jul 2010 13:14:54 +0200 (CEST) Received: from 85.161.90.190 (SquirrelMail authenticated user tv@fuzzy.cz) by sq.gransy.com with HTTP; Thu, 29 Jul 2010 13:14:54 +0200 (CEST) Message-ID: <2727.85.161.90.190.1280402094.squirrel@sq.gransy.com> In-Reply-To: <4C512DD3.9030201@gmail.com> References: <4C50D07D.4040004@gmail.com> <628.1280375626@sss.pgh.pa.us> <4C512DD3.9030201@gmail.com> Date: Thu, 29 Jul 2010 13:14:54 +0200 (CEST) Subject: Re: planner index choice From: tv@fuzzy.cz To: "Chris" Cc: "Tom Lane" , "PostgreSQL Performance" User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.5 tagged_above=-10 required=5 tests=BAYES_05=-0.5 X-Spam-Level: X-Archive-Number: 201007/445 X-Sequence-Number: 39834 > http://explain.depesz.com/s/br9 > http://explain.depesz.com/s/gxH Well, I don't have time to do a thorough analysis right now, but in all the plans you've posted there are quite high values in the "Rows x" column (e.g. the 5727.5 value). That means a significant difference in estimated and actual row number, which may lead to poor choice of indexes etc. The planner may simply think the index is better due to imprecise statistics etc. Try to increase te statistics target for the columns, e.g. ALTER TABLE table ALTER COLUMN column SET STATISTICS integer where "integer" is between 0 and 1000 (the default value is 10 so use 100 or maybe 1000), run analyze and try to run the query again. Tomas