Message-ID: <4277774F.7040205@logix-tt.com>
Date: Tue, 03 May 2005 15:06:23 +0200
From: Markus Schaber <schabi@logix-tt.com>
Organization: Logical Tracking and Tracing International AG, Switzerland
User-Agent: Debian Thunderbird 1.0.2 (X11/20050331)
MIME-Version: 1.0
To: pgsql-perform <pgsql-performance@postgresql.org>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] Bad n_distinct estimation; hacks suggested?
References: <200504191209.05181.josh@agliodbs.com>
	<1114580284.426f253cc0087@webmail.telus.net>
	<426F9703.4010108@dunslane.net>
	<200504270825.17550.josh@agliodbs.com>
In-Reply-To: <200504270825.17550.josh@agliodbs.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi, Josh,

Josh Berkus wrote:

> Yes, actually.   We need 3 different estimation methods:
> 1 for tables where we can sample a large % of pages (say, >= 0.1)
> 1 for tables where we sample a small % of pages but are "easily estimated"
> 1 for tables which are not easily estimated by we can't afford to sample a 
> large % of pages.
> 
> If we're doing sampling-based estimation, I really don't want people to lose 
> sight of the fact that page-based random sampling is much less expensive than 
> row-based random sampling.   We should really be focusing on methods which 
> are page-based.

Would it make sense to have a sample method that scans indices? I think
that, at least for tree based indices (btree, gist), rather good
estimates could be derived.

And the presence of a unique index should lead to 100% distinct values
estimation without any scan at all.

Markus