Odd planner choice?

I'm looking at one of my standard queries and have encountered some strange
performance problems.

The query below is to search for vacant staff member date/time slots given a series of
target date/times. The data contained in the booking_plan/staff_booking tables contain
the existing bookings, so I'm looking for "clashing" bookings to eliminate them from a
candidate list.

The query is:

select distinct b.staff_id from staff_booking b, booking_plan bp, t_search_reqt_dates rd
where b.booking_id = bp.booking_id
and rd.datetime_from <= bp.datetime_to and rd.datetime_to >= bp.datetime_from
AND bp.booking_date between rd.reqt_date-1 and rd.reqt_date+1
and rd.search_id = 13
and rd.reqt_date between '2004-09-30' AND '2005-12-31'

There are 197877 rows in staff_booking, 573416 rows in booking_plan and 26 rows in
t_search_reqt_dates.

The t_search reqt_dates is a temp table created and populated with the target
date/times. The temp table is *not* analyzed, all the other are.

The "good" query plan comes with the criteria on search_id and reqt_date given in the
last two lines in the query. Note all the rows in the temp table are search_id = 13 and all
the rows are between the two dates, so the whole 26 rows is always pulled out.

In this case it is doing exactly what I expect. It is pulling all rows from the
t_search_reqt_dates table, then pulling the relevant records from the booking_plan and
then hashing with staff_booking. Excellent performance.

The problem is I don't need the clauses for search_id and reqt_dates as the whole table
is always read anyway. The good plan is because the planner thinks just one row will be
read from t_search_reqt_dates.

If I remove the redundant clauses, the planner now estimates 1000 rows returned from
the table, not unreasonable since it has no statistics. But *why* in that case, with *more*
estimated rows does it choose to materialize that table (26 rows) 573416 times!!!

whenever it estimates more than one row it chooses the bad plan.

I really want to remove the redundant clauses, but I can't. If I analyse the table, then it
knows there are 26 rows and chooses the "bad" plan whatever I do.

Any ideas???

Cheers,
Gary.

-------------------- Plans for above query ------------------------

Good QUERY PLAN
Unique (cost=15440.83..15447.91 rows=462 width=4) (actual time=1342.000..1342.000
rows=110 loops=1)
-> Sort (cost=15440.83..15444.37 rows=7081 width=4) (actual
time=1342.000..1342.000 rows=2173 loops=1)
Sort Key: b.staff_id
-> Hash Join (cost=10784.66..15350.26 rows=7081 width=4) (actual
time=601.000..1331.000 rows=2173 loops=1)
Hash Cond: ("outer".booking_id = "inner".booking_id)
-> Seq Scan on staff_booking b (cost=0.00..4233.39 rows=197877 width=8)
(actual time=0.000..400.000 rows=197877 loops=1)
-> Hash (cost=10781.12..10781.12 rows=7080 width=4) (actual
time=591.000..591.000 rows=0 loops=1)
-> Nested Loop (cost=0.00..10781.12 rows=7080 width=4) (actual
time=10.000..581.000 rows=2173 loops=1)
Join Filter: (("outer".datetime_from <= "inner".datetime_to) AND
("outer".datetime_to >= "inner".datetime_from))
-> Seq Scan on t_search_reqt_dates rd (cost=0.00..16.50 rows=1
width=20) (actual time=0.000..0.000 rows=26 loops=1)
Filter: ((search_id = 13) AND (reqt_date >= '2004-09-30'::date) AND
(reqt_date <= '2005-12-31'::date))
-> Index Scan using booking_plan_idx2 on booking_plan bp
(cost=0.00..10254.91 rows=63713 width=24) (actual time=0.000..11.538 rows=5871
loops=26)
Index Cond: ((bp.booking_date >= ("outer".reqt_date - 1)) AND
(bp.booking_date <= ("outer".reqt_date + 1)))
Total runtime: 1342.000 ms

Bad QUERY PLAN
Unique (cost=7878387.29..7885466.50 rows=462 width=4) (actual
time=41980.000..41980.000 rows=110 loops=1)
-> Sort (cost=7878387.29..7881926.90 rows=7079211 width=4) (actual
time=41980.000..41980.000 rows=2173 loops=1)
Sort Key: b.staff_id
-> Nested Loop (cost=5314.32..7480762.73 rows=7079211 width=4) (actual
time=6579.000..41980.000 rows=2173 loops=1)
Join Filter: (("inner".datetime_from <= "outer".datetime_to) AND
("inner".datetime_to >= "outer".datetime_from) AND ("outer".booking_date >=
("inner".reqt_date - 1)) AND ("outer".booking_date <= ("inner".reqt_date + 1)))
-> Hash Join (cost=5299.32..26339.73 rows=573416 width=24) (actual
time=2413.000..7832.000 rows=573416 loops=1)
Hash Cond: ("outer".booking_id = "inner".booking_id)
-> Seq Scan on booking_plan bp (cost=0.00..7646.08 rows=573416
width=24) (actual time=0.000..1201.000 rows=573416 loops=1)
-> Hash (cost=4233.39..4233.39 rows=197877 width=8) (actual
time=811.000..811.000 rows=0 loops=1)
-> Seq Scan on staff_booking b (cost=0.00..4233.39 rows=197877
width=8) (actual time=0.000..430.000 rows=197877 loops=1)
-> Materialize (cost=15.00..20.00 rows=1000 width=20) (actual
time=0.001..0.019 rows=26 loops=573416)
-> Seq Scan on t_search_reqt_dates rd (cost=0.00..15.00 rows=1000
width=20) (actual time=0.000..0.000 rows=26 loops=1)
Total runtime: 41980.000 ms