Re: reducing random_page_cost from 4 to 2 to force index scan

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: reducing random_page_cost from 4 to 2 to force index scan
Дата
Msg-id 4DCD2A1C020000250003D6E0@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: reducing random_page_cost from 4 to 2 to force index scan  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-performance
Robert Haas <robertmhaas@gmail.com> wrote:

> We've talked in the past (and I still think it's a good idea, but
> haven't gotten around to doing anything about it) about adjusting
> the planner to attribute to each relation the percentage of its
> pages which we believe we'll find in cache.  Although many
> complicated ideas for determining that percentage have been
> proposed, my favorite one is fairly simple: assume that small
> relations will be mostly or entirely cached, and that big ones
> won't be.   Allow the administrator to override the result on a
> per-relation basis.  It's difficult to imagine a situation where
> the planner should assume that a relation with only handful of
> pages isn't going to be cached.  Even if it isn't, as soon as
> someone begins accessing it, it will be.

Simple as the heuristic is, I bet it would be effective.  While one
can easily construct a synthetic case where it falls down, the ones
I can think of aren't all that common, and you are suggesting an
override mechanism.

-Kevin

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: reducing random_page_cost from 4 to 2 to force index scan
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [PERFORMANCE] expanding to SAN: which portion best to move