From: Markus Schaber <schabi@logix-tt.com>
To: pgsql-perform <pgsql-performance@postgresql.org>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] Bad n_distinct estimation; hacks suggested?
Date: Tue, 03 May 2005 15:06:23 +0200
Message-ID: <4277774F.7040205@logix-tt.com> (raw)
In-Reply-To: <200504270825.17550.josh@agliodbs.com>
References: <200504191209.05181.josh@agliodbs.com>
<1114580284.426f253cc0087@webmail.telus.net>
<426F9703.4010108@dunslane.net>
<200504270825.17550.josh@agliodbs.com>
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
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: schabi@logix-tt.com, pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] Bad n_distinct estimation; hacks suggested?
In-Reply-To: <4277774F.7040205@logix-tt.com>
* 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