Re: Using bitmap index scans-more efficient

Kyle Bateman <kyle@actarg.com> writes:
> Tom Lane wrote:
>> Before 8.2 the optimizer has no ability to rearrange the order of outer
>> joins.  Do you have time to try your test case against CVS HEAD?

> OK, I figured it out--grabbed the latest snapshot (hope that is what you 
> need).
> My results are similar:

Are you sure you found a recent version?  I get this from CVS HEAD:

ledger=# explain analyze select l.* from ledg_v2 l, proj p where l.proj = p.proj_id and 5 = p.par;
                                    QUERY PLAN                                                            
 

----------------------------------------------------------------------------------------------------------------------------------Nested
LoopLeft Join  (cost=5.79..1386.74 rows=400 width=23) (actual time=0.125..1.543 rows=329 loops=1)  ->  Nested Loop
(cost=4.66..1377.61rows=400 width=19) (actual time=0.109..1.072 rows=329 loops=1)        ->  Index Scan using
i_proj_paron proj p  (cost=0.00..8.41 rows=5 width=4) (actual time=0.023..0.028 rows=4 loops=1)              Index
Cond:(5 = par)        ->  Bitmap Heap Scan on ledg l  (cost=4.66..272.83 rows=81 width=19) (actual time=0.073..0.213
rows=82loops=4)              Recheck Cond: (l.proj = p.proj_id)              ->  Bitmap Index Scan on i_ledg_proj
(cost=0.00..4.66rows=81 width=0) (actual time=0.041..0.041 rows=82 loops=4)                    Index Cond: (l.proj =
p.proj_id) ->  Materialize  (cost=1.13..1.14 rows=1 width=4) (actual time=0.000..0.000 rows=1 loops=329)        ->  Seq
Scanon acct a  (cost=0.00..1.12 rows=1 width=4) (actual time=0.009..0.011 rows=1 loops=1)              Filter:
((code)::text= 'ap'::text)Total runtime: 1.696 ms
 
(12 rows)

Yours is doing the left join inside the join to proj, which of course is
terrible because it has to form the whole 400K-row join result.
        regards, tom lane