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 9943D52801 for ; Tue, 28 Jun 2005 13:27:40 -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 70010-09 for ; Tue, 28 Jun 2005 16:27:30 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by svr1.postgresql.org (Postfix) with ESMTP id 7CB82529E3 for ; Tue, 28 Jun 2005 13:27:29 -0300 (ADT) Received: (qmail 14544 invoked from network); 28 Jun 2005 16:27:29 -0000 Received: from dsl093-114-095.chi2.dsl.speakeasy.net (HELO mofo.meme.com) ([66.93.114.95]) (envelope-sender ) by mail22.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 28 Jun 2005 16:27:29 -0000 Received: from mofo (localhost.localdomain [127.0.0.1]) by mofo.meme.com (Postfix) with ESMTP id 060756E421; Tue, 28 Jun 2005 12:16:41 -0500 (CDT) Date: Tue, 28 Jun 2005 17:16:41 +0000 From: "Karl O. Pinc" Subject: Re: Poor index choice -- multiple indexes of the same To: Tom Lane Cc: pgsql-performance@postgresql.org References: <1119913766l.4428l.2l@mofo> <11497.1119940856@sss.pgh.pa.us> In-Reply-To: <11497.1119940856@sss.pgh.pa.us> (from tgl@sss.pgh.pa.us on Tue Jun 28 01:40:56 2005) X-Mailer: Balsa 2.3.0 Message-Id: <1119979001l.20199l.7l@mofo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.05 tagged_above=0 required=5 tests=FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200506/567 X-Sequence-Number: 13204 On 06/28/2005 01:40:56 AM, Tom Lane wrote: > "Karl O. Pinc" writes: > > I have a query > > > select 1 > > from census > > where date < '1975-9-21' and sname = 'RAD' and status != 'A' > > limit 1; > > > Explain analyze says it always uses the index made by: > > > CREATE INDEX census_date_sname ON census (date, sname); > > > this is even after I made the index: > > > CREATE INDEX census_sname_date ON census (sname, date); > > I don't believe that any existing release can tell the difference > between these two indexes as far as costs go. I just recently > added some code to btcostestimate that would cause it to prefer > the index on (sname, date) but of course that's not released yet. > > However: isn't the above query pretty seriously underspecified? > With a LIMIT and no ORDER BY, you are asking for a random one > of the rows matching the condition. I realize that with > "select 1" you may not care much, but adding a suitable ORDER BY > would help push the planner towards using the right index. In > this case "ORDER BY sname DESC, date DESC" would probably do the > trick. Yes, that works. I'd already tried "ORDER BY date DESC", before I first wrote, and that did not work. (I started with no LIMIT either, and tried adding specifications until I gave up. It's very good that the new planner will figure out things by itself.) "ORDER BY sname DESC" works as well. This is a bit odd, as with the constant in the = comparison "ORDER BY date DESC" is the same as "ORDER BY sname DESC, date DESC". I guess that's why I gave up on my attempts to get the planner to use the (sname, date) index before I got to your solution. Thanks everybody for the help. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein