Re: Analyzer is clueless

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?"

In response to

Responses

Browse pgsql-performance by date

  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