Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

Next:From: Josh BerkusDate: 2004-11-18 01:41:16
Subject: Re: Analyzer is clueless
Previous:From: Tom LaneDate: 2004-11-17 23:38:40
Subject: Re: postgres eating CPU

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group