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 BANLkTikTWeZxWQFxM1SJg=0=OtCkCX_-dA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: reducing random_page_cost from 4 to 2 to force index scan  (Jesper Krogh <jesper@krogh.cc>)
Ответы Re: reducing random_page_cost from 4 to 2 to force index scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Mon, May 16, 2011 at 12:49 AM, Jesper Krogh <jesper@krogh.cc> wrote:
>> To me it seems like a robust and fairly trivial way to to get better
>> numbers. The
>> fear is that the OS-cache is too much in flux to get any stable numbers
>> out
>> of it.
>
> Ok, it may not work as well with index'es, since having 1% in cache may very
> well mean that 90% of all requested blocks are there.. for tables in should
> be more trivial.

Tables can have hot spots, too.  Consider a table that holds calendar
reservations.  Reservations can be inserted, updated, deleted.  But
typically, the most recent data will be what is most actively
modified, and the older data will be relatively more (though not
completely) static, and less frequently accessed.  Such examples are
common in many real-world applications.

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

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

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