strange plan with bitmap heap scan and multiple partial indexes

Hi,

While working on the "IOS with partial indexes" patch, I've noticed a 
bit strange plan. It's unrelated to that particular patch (reproducible 
on master), so I'm starting a new thread for it.

To reproduce it, all you have to do is this (on a new cluster, all 
settings on default):
  CREATE TABLE t AS SELECT i AS a, i AS b                      FROM generate_series(1,10000000) s(i);
  CREATE INDEX idx001 ON t (a) where b < 100;  CREATE INDEX idx002 ON t (a) where b < 200;  CREATE INDEX idx003 ON t
(a)where b < 300;
 
  ANALYZE t;
  EXPLAIN SELECT a FROM t WHERE b < 100;
                        QUERY PLAN
-------------------------------------------------------------------- Bitmap Heap Scan on t  (cost=9.01..13.02 rows=1000
width=4)  Recheck Cond: ((b < 300) AND (b < 200))   Filter: (b < 100)   ->  BitmapAnd  (cost=9.01..9.01 rows=1 width=0)
       ->  Bitmap Index Scan on idx003                            (cost=0.00..4.13 rows=1000 width=0)         ->
BitmapIndex Scan on idx002                            (cost=0.00..4.13 rows=1000 width=0)
 

Now, that's strange IMHO. There's a perfectly matching partial index, 
with exactly the same predicate (b<100), but we instead choose the two 
other indexes, and combine them using BitmapAnd. That seems a bit 
strange - choosing one of them over the perfectly matching one would be 
strange too, but why use two and combine them?

Another thing is that this gets fixed by a simple VACUUM on the table.
  EXPLAIN SELECT a FROM t WHERE b < 100;
                             QUERY PLAN
-------------------------------------------------------------------- Index Scan using idx001 on t  (cost=0.14..29.14
rows=1000width=4)
 


Any idea what's going on here? FWIW all this was on 51d0fe5d (July 23).

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services