Re: Revisiting default_statistics_target

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Revisiting default_statistics_target
Date: 2009-05-22 17:38:45
Message-ID: 27799.1243013925@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> Yesterday Jignesh Shah presented his extensive benchmark results comparing
> 8.4-beta1 with 8.3.7 at PGCon:
> http://blogs.sun.com/jkshah/entry/pgcon_2009_performance_comparison_of

> While most cases were dead even or a modest improvement, his dbt-2 results
> suggest a 15-20% regression in 8.4. Changing the default_statistics_taget
> to 100 was responsible for about 80% of that regression. The remainder
> was from the constraint_exclusion change. That 80/20 proportion was
> mentioned in the talk but not in the slides. Putting both those back to
> the 8.3 defaults swapped things where 8.4b1 was ahead by 5% instead.

Yeah, I saw that talk and I'm concerned too, but I think it's premature
to conclude that the problem is precisely that stats_target is now too
high. I'd like to see Jignesh check through the individual queries in
the test and make sure that none of them had plans that changed for the
worse. The stats change might have just coincidentally tickled some
other planning issue.

Assuming that we do confirm that the hit comes from extra stats
processing time during planning, I'd still not want to go all the way
back to 10 as default. Perhaps we'd end up compromising at something
like 50.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2009-05-22 17:39:08 Re: Revisiting default_statistics_target
Previous Message Stephen Frost 2009-05-22 17:35:32 Re: Revisiting default_statistics_target