Re: Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)

Andrew Sagulin <andrews42(at)yandex(dot)ru> writes:
> Does PostgreSQL's development team plan to revise the index scan
> cost algorithm or issues like mine is too rare for taking into account?

The algorithm is certainly open for discussion, but we're not changing
it on the basis of just a single report ...

You're mistaken to be fingering min_IO_cost as the source of the issue,
because there is also a correction for near-sequential access in
cost_bitmap_heap_scan. If we were to bias the system as heavily against
the consideration as you propose, we would logically have to put a
similar bias into cost_bitmap_heap_scan, and you'd probably still end up
with a plain indexscan. What you need to do is compare the two
functions and figure out what part of the cost models are out of line
with reality. I tend to agree with the upthread comment that the
nonlinear interpolation between min_IO_cost and max_IO_cost is suspect
... but that may or may not have anything truly to do with your problem.
It might be that cost_index is fine and cost_bitmap_heap_scan is
overcharging.

BTW there are already some changes in HEAD relating to this, please see
the pghackers archives from beginning of June (thread "More thoughts
about planner's cost estimates").

regards, tom lane