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

Re: [PATCHES] Better default_statistics_target

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, Decibel! <decibel(at)decibel(dot)org>, "Christopher Browne" <cbbrowne(at)gmail(dot)com>, "Greg Sabino Mullane" <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Better default_statistics_target
Date: 2008-01-31 00:19:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
"Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> writes:
> On Jan 31, 2008 12:08 AM, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>> That's not my experience. Even just raising it to 100 multiplies the number of
>> rows ANALYZE has to read by 10. And the arrays for every column become ten
>> times larger. Eventually they start being toasted...

> +1. From the tests I did on our new server, I set the
> default_statistict_target to 30. Those tests were mainly based on the
> ANALYZE time though, not the planner overhead introduced by larger
> statistics - with higher values, I considered the ANALYZE time too
> high for the benefits.

eqjoinsel(), for one, is O(N^2) in the number of MCV values kept.
Possibly this could be improved, but in general I'd be real wary
of pushing the default to the moon without some explicit testing of
the impact on planning time.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-01-31 01:13:14
Subject: Re: Oops - BF:Mastodon just died
Previous:From: Tom LaneDate: 2008-01-30 23:50:54
Subject: Re: Oops - BF:Mastodon just died

pgsql-patches by date

Next:From: Bruce MomjianDate: 2008-01-31 01:33:33
Subject: Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable
Previous:From: Guillaume SmetDate: 2008-01-30 23:36:32
Subject: Re: [PATCHES] Better default_statistics_target

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