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

Re: Simple postgresql.conf wizard

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Decibel! <decibel(at)decibel(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Dann Corbit" <DCorbit(at)connx(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Mark Wong" <markwkm(at)gmail(dot)com>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Josh Berkus" <josh(at)agliodbs(dot)com>, "Greg Smith" <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Simple postgresql.conf wizard
Date: 2008-11-26 01:06:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Decibel! <decibel(at)decibel(dot)org> writes:

> Is there even a good way to find out what planning time was? Is there  a way to
> gather that stat for every query a session runs?

explain select ...

> The thought occurs to me that we're looking at this from the wrong  side of the
> coin. I've never, ever seen query plan time pose a  problem with Postgres, even
> without using prepared statements. 

I certainly have seen plan times be a problem. I wonder if you have too and
just didn't realize it. With a default_stats_target of 1000 you'll have
hundreds of kilobytes of data to slog through to plan a moderately complex
query with a few text columns. Forget about prepared queries, I've seen plan
times be unusable for ad-hoc interactive queries before.

> We've been talking about changing default_stats_target for at least 2  or 3
> years now. We know that the current value is causing problems.  Can we at least
> start increasing it? 30 is pretty much guaranteed to  be better than 10, even
> if it's nowhere close to an ideal value. If  we start slowly increasing it then
> at least we can start seeing where  people start having issues with query plan
> time.

How would you see anything from doing that? We only hear from people who have
problems so we only see half the picture. You would have no way of knowing
whether your change has helped or hurt anyone.

In any case I don't see "we know that the current value is causing problems"
as a reasonable statement. It's the *default* stats target. There's a reason
there's a facility to raise the stats target for individual columns.

As Dann said, "the idea that there IS a magic number is the problem". *Any*
value of default_stats_target will "cause" problems. Some columns will always
have skewed data sets which require unusually large samples, but most won't
and the system will run faster with a normal sample size for that majority.

The question is what value represents a good trade-off between the costs of
having large stats targets -- longer analyze, more data stored in
pg_statistics, more vacuuming of pg_statistics needed, longer plan times --
and the benefits of having larger stats targets -- fewer columns which need
raised stats targets.

  Gregory Stark
  Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

In response to


pgsql-hackers by date

Next:From: Dann CorbitDate: 2008-11-26 01:18:59
Subject: Re: Simple postgresql.conf wizard
Previous:From: KaiGai KoheiDate: 2008-11-26 00:45:13
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1197)

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