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?
