X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id AB5CE5284D for ; Fri, 3 Jun 2005 20:22:58 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 01958-03 for ; Fri, 3 Jun 2005 23:22:54 +0000 (GMT) Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by svr1.postgresql.org (Postfix) with ESMTP id B44F552816 for ; Fri, 3 Jun 2005 20:22:53 -0300 (ADT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 865F330952; Sat, 4 Jun 2005 01:19:22 +0200 (MET DST) From: William Yu X-Newsgroups: pgsql.performance Subject: Re: Forcing use of specific index Date: Fri, 03 Jun 2005 16:22:49 -0700 Organization: Hub.Org Networking Services Lines: 23 Message-ID: References: <20050602020528.GL26100@tobias.exoweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en In-Reply-To: <20050602020528.GL26100@tobias.exoweb.net> To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200506/80 X-Sequence-Number: 12718 A pretty awful way is to mangle the sql statement so the other field logical statements are like so: select * from mytable where 0+field = 100 Tobias Brox wrote: > Is it any way to attempt to force the planner to use some specific index > while creating the plan? Other than eventually dropping all the other > indices (which is obiously not a solution in production setting anyway)? > > I have one case where I have added 16 indices to a table, many of them > beeing partial indices. The table itself has only 50k of rows, but are > frequently used in heavy joins. I imagine there can be exponential order on > the number of alternative paths the planner must examinate as function of > the number of indices? > > It seems to me that the planner is quite often not choosing the "best" > index, so I wonder if there is any easy way for me to check out what the > planner think about a specific index :-) >