Re: Revisiting default_statistics_target

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Revisiting default_statistics_target
Дата
Msg-id 27799.1243013925@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Revisiting default_statistics_target  (Greg Smith <gsmith@gregsmith.com>)
Ответы Re: Revisiting default_statistics_target  (andrew@dunslane.net)
Re: Revisiting default_statistics_target  (Mark Wong <markwkm@gmail.com>)
Список pgsql-hackers
Greg Smith <gsmith@gregsmith.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Revisiting default_statistics_target
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Revisiting default_statistics_target