On Tue, 18 Apr 2006 15:51:44 -0400
Tom Lane <tgl@xxxxxxxxxxxxx> 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.
