Index scan plan estimates way off.

[Jonathan Hseu <vomjom@xxxxxxxxxx>]

I have a relatively simple query with a single index on (contract_id, time):

vjtrade=> EXPLAIN SELECT * FROM ticks WHERE contract_id=1 ORDER BY time;

               QUERY PLAN                                             
-----------------------------------------------------------------------------------------------------
 Sort  (cost=11684028.44..11761274.94 rows=30898601 width=40)
   Sort Key: "time"
   ->  Bitmap Heap Scan on ticks  (cost=715657.57..6995196.08 rows=30898601 width=40)
         Recheck Cond: (contract_id = 1)
         ->  Bitmap Index Scan on contract_id_time_idx  (cost=0.00..707932.92 rows=30898601 width=0)
               Index Cond: (contract_id = 1)
(6 rows)

This plan doesn't complete in a reasonable amount of time.  I end up having to kill the query after it's been running for over an hour.

If I do a:
SET enable_sort=FALSE;
SET enable_bitmapscan=FALSE;

Then it gives me this plan:

Index Scan using contract_id_time_idx on ticks  (cost=0.00..117276552.51 rows=30897044 width=40) (actual time=34.025..738583.609 rows=27858174 loops=1)
  Index Cond: (contract_id = 1)
Total runtime: 742323.102 ms

Notice how the estimated cost is so much different from the actual time.  The row estimate is pretty good, however.

This is on postgresql 8.3.5 with:
shared_buffers = 512MB
temp_buffers = 256MB
work_mem = 256MB
max_fsm_pages = 153600
effective_cache_size = 1500MB

Is there any way to give postgresql a better estimate of the index scan time?  I tried setting random_page_cost=1, but it still gave me the bitmap plan.

Thanks,
Jonathan Hseu