Re: Slow query - possible bug?

On Tue, 18 Apr 2006 15:51:44 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Fair enough, no reason to replace one workaround with another. But
> would you try it on your test case, just to verify the diagnosis?

Yup I can confirm it from testing earlier today - as soon as
the two dates are non-equal, an index scan is correctly selected and
returns results in just a few milliseconds:

laterooms=# explain analyse select allocation0_."ID" as y1_,
allocation0_."RoomID" as y2_, allocation0_."StatusID" as y4_,
allocation0_."Price" as y3_, allocation0_."Number" as y5_,
allocation0_."Date" as y6_ from "Allocation" allocation0_ where
(allocation0_."Date" between '2006-04-25 00:00:00.000000' and
'2006-04-26 00:00:00.000000')and(allocation0_."RoomID" in(211800));
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using ix_dateroom on "Allocation" allocation0_
(cost=0.00..14.02 rows=4 width=34) (actual time=16.799..21.804 rows=2
loops=1) Index Cond: (("RoomID" = 211800) AND ("Date" >=
'2006-04-25'::date) AND ("Date" <= '2006-04-26'::date))
Total runtime: 21.910 ms

which I ran first, versus the identical-date equivalent which turned
in a whopping...

Index Scan using ix_date on "Allocation" allocation0_
(cost=0.00..4.77 rows=1 width=34) (actual time=6874.272..69541.064
rows=1 loops=1) Index Cond: (("Date" >= '2006-04-25'::date) AND ("Date"
<= '2006-04-25'::date)) Filter: ("RoomID" = 211800) Total runtime:
69541.113 ms (4 rows)

Cheers,
Gavin.