Lookup with an inefficient index

Is this new index worth being created? Consider a simple query that uses it to filter out based on the value:

EXPLAIN ANALYZE SELECT count(*) FROM t WHERE v=1;
QUERY PLAN
----------
Aggregate  (cost=756.55..756.56 rows=1 width=0) (actual time=31.962..31.963 rows=1 loops=1)
   ->  Bitmap Heap Scan on t  (cost=165.01..731.79 rows=9903 width=0) (actual time=1.821..18.010 rows=10054 loops=1)
         Recheck Cond: (v = 1)
         ->  Bitmap Index Scan on i  (cost=0.00..162.53 rows=9903 width=0) (actual time=1.721..1.721 rows=10054 loops=1)
               Index Cond: (v = 1)
 Total runtime: 32.019 ms

relname        | t
seq_scan       | 1
seq_tup_read   | 100000
idx_scan       | 1
idx_tup_fetch  | 10054
heap_blks_read | 0
heap_blks_hit  | 886
idx_blks_read  | 25
idx_blks_hit   | 0

We expect 1/10 of the table, or around 10,000 rows, to be returned by the index scan, and that's what happens (9903 in this case). It is effectively doing two scans...