From: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | David Brown <time(at)bigpond(dot)net(dot)au>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Analyzer is clueless |
Date: | 2004-11-18 00:20:09 |
Message-ID: | 20041118002008.GL80532@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Nov 17, 2004 at 10:32:48PM +0000, Simon Riggs wrote:
> The main issue is that PostgreSQL's default histogram statistics setting
> is lower than other RDBMS. This means that it is less able to
> discriminate between cases such as yours that are close to the edge.
> This is a trade-off between run-time of the ANALYZE command and the
> benefit it produces. As Joshua suggests, increasing the statistics
> target for this table will likely allow the optimizer to correctly
> determine the selectivity of the index and take the right path.
Is there still a good reason to have the histogram stats so low? Should
the default be changed to more like 100 at this point?
Also, how extensively does the planner use n_distinct, null_frac,
reltuples and the histogram to see what the odds are of finding a unique
value or a low number of values? I've seen cases where it seems the
planer doesn't think it'll be getting a unique value or a small set of
values even though stats indicates that it should be.
One final question... would there be interest in a process that would
dynamically update the histogram settings for tables based on how
distinct/unique each field was?
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-11-18 01:41:16 | Re: Analyzer is clueless |
Previous Message | Tom Lane | 2004-11-17 23:38:40 | Re: postgres eating CPU |