Re: Maximum statistics target - Mailing list pgsql-hackers

From Guillaume Smet
Subject Re: Maximum statistics target
Date
Msg-id 1d4e0c10803100528w5b994471ja0253bd898e9a0d6@mail.gmail.com
Whole thread Raw
In response to Re: Maximum statistics target  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Mon, Mar 10, 2008 at 11:36 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
>  The time to analyze is also quite constant, just before you run out of
>  memory. :)  The MaxAllocSize is the limiting factor in all this.  In my
>  example, statistics targets larger than about 800000 created pg_statistic
>  rows that would have been larger than 1GB, so they couldn't be stored.

From my experience on real life examples, the time to analyze is far
from being constant when you raise the statistics target but it may be
related to the schema of our tables.

cityvox=# \timing
Timing is on.
cityvox=# show default_statistics_target ;default_statistics_target
---------------------------10
(1 row)

Time: 0.101 ms
cityvox=# ANALYZE evenement;
ANALYZE
Time: 406.069 ms
cityvox=# ANALYZE evenement;
ANALYZE
Time: 412.355 ms
cityvox=# set default_statistics_target = 30;
SET
Time: 0.165 ms
cityvox=# ANALYZE evenement;
ANALYZE
Time: 1419.161 ms
cityvox=# ANALYZE evenement;
ANALYZE
Time: 1381.754 ms
cityvox=# set default_statistics_target = 100;
SET
Time: 1.853 ms
cityvox=# ANALYZE evenement;
ANALYZE
Time: 5211.785 ms
cityvox=# ANALYZE evenement;
ANALYZE
Time: 5178.764 ms

That said I totally agree that it's not a good idea to have a strict
maximum value if we haven't technical reasons for that.

--
Guillaume


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Include Lists for Text Search
Next
From: "Michał Zaborowski"
Date:
Subject: Re: Lazy constraints / defaults