X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 04F529DC816 for ; Wed, 15 Mar 2006 15:17:54 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 09576-01 for ; Wed, 15 Mar 2006 15:17:54 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id CA4A39DCCB2 for ; Wed, 15 Mar 2006 15:17:49 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k2FJHoBg028799; Wed, 15 Mar 2006 14:17:50 -0500 (EST) To: "Kevin Grittner" cc: pgsql-performance@postgresql.org, "Andreas Kretschmer" Subject: Re: BETWEEN optimizer problems with single-value In-reply-to: <44180D33.EE98.0025.0@wicourts.gov> References: <44180105.EE98.0025.0@wicourts.gov> <20060315181735.GA22240@KanotixBox> <44180D33.EE98.0025.0@wicourts.gov> Comments: In-reply-to "Kevin Grittner" message dated "Wed, 15 Mar 2006 12:48:51 -0600" Date: Wed, 15 Mar 2006 14:17:50 -0500 Message-ID: <28798.1142450270@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.112 required=5 tests=[AWL=0.112] X-Spam-Score: 0.112 X-Spam-Level: X-Archive-Number: 200603/213 X-Sequence-Number: 17650 "Kevin Grittner" writes: >> Odd. Can you tell us your PG- Version? > this is 8.1.2 with some 8.1.3 changes plus the string literal patch.) 8.1 is certainly capable of devising the plan you want, for example in the regression database: regression=# explain select * from tenk1 where thousand = 10 and tenthous between 42 and 144; QUERY PLAN ------------------------------------------------------------------------------------ Index Scan using tenk1_thous_tenthous on tenk1 (cost=0.00..6.01 rows=1 width=244) Index Cond: ((thousand = 10) AND (tenthous >= 42) AND (tenthous <= 144)) (2 rows) It looks to me like this is a matter of bad cost estimation, ie, it's thinking the other index is cheaper to use. Why that is is not clear. Can we see the pg_stats rows for ctofcNo and calDate? Also, try to force it to generate the plan you want, so we can see what it thinks the cost is for that. If you temporarily drop the wrong index you should be able to get there: begin; drop index "Cal_CalDate"; explain analyze select ... ; -- repeat as needed if it chooses some other wrong index rollback; I hope you have a play copy of the database to do this in --- although it would be safe to do the above in a live DB, the DROP would exclusive-lock the table until you finish the experiment and rollback, which probably is not good for response time ... regards, tom lane