Index-only scan and random_page_cost

Index-only scan and random_page_cost

Hi hackers,

Right now cost of index-only scan is using `random_page_cost`.
Certainly for point selects we really have random access pattern, but 
queries like "select count(*) from hits"  access pattern is more or less 
sequential:
we are iterating through subsequent leaf B-Tree pages.  As far as 
default value of `random_page_cost`  is 4 times larger than `seq_page_cost`
it may force Postgres optimizer to choose sequential scan, while 
index-only scan is usually much faster in this case.
Can we do something here to provide more accurate cost estimation?