Re: [PATCHES] Better default_statistics_target

Поиск
Список
Период
Сортировка
Искать
От
Guillaume Smet
Тема
Re: [PATCHES] Better default_statistics_target
Дата
Msg-id
1d4e0c10712050949q783d0084u10f1313b3750414a@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Re: [PATCHES] Better default_statistics_target "Guillaume Smet" <guillaume.smet@gmail.com>
Re: [PATCHES] Better default_statistics_target Decibel! <decibel@decibel.org>
Re: [PATCHES] Better default_statistics_target "Christopher Browne" <cbbrowne@gmail.com>
Re: [PATCHES] Better default_statistics_target Decibel! <decibel@decibel.org>
Re: [PATCHES] Better default_statistics_target Gregory Stark <stark@enterprisedb.com>
Re: [PATCHES] Better default_statistics_target "Guillaume Smet" <guillaume.smet@gmail.com>
Re: [PATCHES] Better default_statistics_target Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCHES] Better default_statistics_target "Christopher Browne" <cbbrowne@gmail.com>
Re: [PATCHES] Better default_statistics_target Decibel! <decibel@decibel.org>
Re: [PATCHES] Better default_statistics_target Alvaro Herrera <alvherre@commandprompt.com>
Re: [PATCHES] Better default_statistics_target "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: [PATCHES] Better default_statistics_target Robert Treat <xzilla@users.sourceforge.net>
Re: [PATCHES] Better default_statistics_target "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: [PATCHES] Better default_statistics_target Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCHES] Better default_statistics_target "Heikki Linnakangas" <heikki@enterprisedb.com>
Re: [PATCHES] Better default_statistics_target "Greg Sabino Mullane" <greg@turnstep.com>
On Dec 5, 2007 3:26 PM, Greg Sabino Mullane  wrote:
> Agreed, this would be a nice 8.4 thing. But what about 8.3 and 8.2? Is
> there a reason not to make this change? I know I've been lazy and not run
> any absolute figures, but rough tests show that raising it (from 10 to
> 100) results in a very minor increase in analyze time, even for large
> databases. I think the burden of a slightly slower analyze time, which
> can be easily adjusted, both in postgresql.conf and right before running
> an analyze, is very small compared to the pain of some queries - which worked
> before - suddenly running much, much slower for no apparent reason at all.

As Tom stated it earlier, the ANALYZE slow down is far from being the
only consequence. The planner will also have more work to do and
that's the hard point IMHO.

Without studying the impacts of this change on a large set of queries
in different cases, it's quite hard to know for sure that it won't
have a negative impact in a lot of cases.

It's a bit too late in the cycle to change that IMHO, especially
without any numbers.

--
Guillaume
В списке pgsql-hackers по дате отправления
От: Guillaume Lelarge
Дата:
От: Alvaro Herrera
Дата:
Сообщение: Re: Open items for 8.3
FAQ