Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)

Wednesday, June 28, 2006, 2:04:17 Simon Riggs, you wrote:

> That part is sensible. The min_IO_cost is when the access is sequential,
> which by definition has a cost of 1.0.

In general - yes. But we talk about the min_IO_cost of the index scan which is
barely sequential. Correct me if I'm wrong: index scan algorithm is something
like this: 'read couple of index pages, read some data pages, index pages, data
pages, ...'. So, the current assumption of min_IO_cost is too optimistic even in
a case of ideal tuple ordering.

> The bit you might have issue with is how we extrapolate from the
> min_IO_cost and correlation to arrive at a cost.

Now index scan cost calculation use indexCorrelation as measure of a tuple
clustering and a degree of their sequentiality (physical ordering). As far
as I know there are cases when this approach is wrong, for example, my issue or
any other case with high clustering without ordering, where bitmap heap scan is
the best way but PostgreSQL prefer index scan or even sequential scan.

Does PostgreSQL's development team plan to revise the index scan
cost algorithm or issues like mine is too rare for taking into account?