From: Andrew Sagulin <andrews42@yandex.ru>
To: pgsql-performance@postgresql.org
Subject: Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)
Date: Wed, 28 Jun 2006 13:33:55 +0400
Message-ID: <624168784.20060628133355@yandex.ru> (raw)
In-Reply-To: <1151445858.2479.170.camel@localhost.localdomain>
References: <463024718.20060627161408@yandex.ru>
<1151445858.2479.170.camel@localhost.localdomain>
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?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: andrews42@yandex.ru
Subject: Re: Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)
In-Reply-To: <624168784.20060628133355@yandex.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox