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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: reducing random_page_cost from 4 to 2 to force index scan
Дата
Msg-id BANLkTi=BTJ56m-OozcD8fH2kkHOqmA4fHA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: reducing random_page_cost from 4 to 2 to force index scan  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: reducing random_page_cost from 4 to 2 to force index scan  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-performance
On Fri, May 13, 2011 at 4:13 PM, Josh Berkus <josh@agliodbs.com> wrote:
> Instead, we should be fixing the formulas these are based on and leaving
> RPC alone.
>
> For any data page, there are actually four costs associated with each
> tuple lookup, per:

All true.  I suspect that in practice the different between random and
sequential memory page costs is small enough to be ignorable, although
of course I might be wrong.  I've never seen a database that was fully
cached in memory where it was necessary to set
random_page_cost>seq_page_cost to get good plans -- no doubt partly
because even if the pages were consecutive on disk, there's no reason
to suppose they would be so in memory, and we certainly wouldn't know
one way or the other at planning time.   But I agree we should add a
cached_page_cost as part of all this.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Предыдущее
От: John Rouillard
Дата:
Сообщение: Using pgiosim realistically
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Query improvement