Re: 7.2.1 optimises very badly against 7.2

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: 7.2.1 optimises very badly against 7.2
Дата
Msg-id Pine.LNX.4.44.0207121512520.11521-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: 7.2.1 optimises very badly against 7.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On Fri, 12 Jul 2002, Tom Lane wrote:

> "Sam Liddicott" <sam.liddicott@ananova.com> writes:
> > Do you feel the random page cost of 3 is good to solve this?
>
> For the moment, anyway.  There have been a couple of rounds of
> pgsql-hackers discussion about whether to lower the default value of
> random_page_cost, but so far no one has done any experiments that
> would be needed to establish a good new value.  (The current default
> of 4.0 is based on some old experiments I did.  I'm quite willing to
> accept that those experiments might have been flawed, but not willing
> to replace the number without seeing better experiments...)

When I first started using the 7.x series, the query planner often picked
a sequential scan that would take minutes to return, when an index scan
would take seconds.  A very low setting for random page cost would fix
this (a setting of 0.1 or something like that) but would also make the
planner make some bad choices where it should be picking a seq scan but
didn't.

With 7.2 I've found that a random page cost of around 2 to 4 seems to work
very well.

So, my point (and I have one!) is that previous experiences with random
page cost and older versions of postgresql don't necessarily apply to
postgresql 7.2.1.  Also, if you're having problems with the query planner
and you're running a version of postgresql from before 7.2, you should
upgrade first, then worry about what random page cost should be set to.


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

Предыдущее
От: terry@greatgulfhomes.com
Дата:
Сообщение: looking up field names
Следующее
От: suga@netbsd.com.br
Дата:
Сообщение: Re: I am being interviewed by OReilly