| 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: | 27192.1201738793@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-01-31 01:13:14 | Re: Oops - BF:Mastodon just died |
| Previous Message | Tom Lane | 2008-01-30 23:50:54 | Re: Oops - BF:Mastodon just died |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2008-01-31 01:33:33 | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |
| Previous Message | Guillaume Smet | 2008-01-30 23:36:32 | Re: [PATCHES] Better default_statistics_target |