X-Original-To: pgsql-performance-postgresql.org@postgresql.org
Received: from localhost (mx1.hub.org [200.46.208.251])
	by postgresql.org (Postfix) with ESMTP id 0F9E39FA5F0
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 28 Jun 2006 06:34:14 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024)
	with ESMTP id 19903-10 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Wed, 28 Jun 2006 06:34:08 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from smtp1.yandex.ru (smtp1.yandex.ru [213.180.223.87])
	by postgresql.org (Postfix) with ESMTP id 4E2719FA2F0
	for <pgsql-performance@postgresql.org>;
	Wed, 28 Jun 2006 06:34:07 -0300 (ADT)
Received: from proxy2.upr.belsvyaz.ru ([82.151.104.10]:35903 "EHLO
	server42.gts.gptus.com" smtp-auth: "andrews42" TLS-CIPHER: <none>
	TLS-PEER-CN1: <none>) by mail.yandex.ru with ESMTP id S2078029AbWF1Jd5
	(ORCPT <rfc822;pgsql-performance@postgresql.org>);
	Wed, 28 Jun 2006 13:33:57 +0400
X-Comment: RFC 2476 MSA function at smtp1.yandex.ru logged sender identity as:
	andrews42
Date: Wed, 28 Jun 2006 13:33:55 +0400
From: Andrew Sagulin <andrews42@yandex.ru>
X-Mailer: The Bat! (v3.62.14) Professional
Reply-To: Andrew Sagulin <andrews42@yandex.ru>
Organization: gPTUS
X-Priority: 3 (Normal)
Message-ID: <624168784.20060628133355@yandex.ru>
To: pgsql-performance@postgresql.org
Subject: Large index scan perfomance and indexCorrelation (PG 8.1.4 Win32)
In-Reply-To: <1151445858.2479.170.camel@localhost.localdomain>
References: <463024718.20060627161408@yandex.ru>
	<1151445858.2479.170.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200606/484
X-Sequence-Number: 19841

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?