Re: Read/Write block sizes (Was: Caching by Postgres)

Поиск
Список
Период
Сортировка
От Michael Stone
Тема Re: Read/Write block sizes (Was: Caching by Postgres)
Дата
Msg-id 20050823231238.GL8667@mathom.us
обсуждение исходный текст
Ответ на Re: Read/Write block sizes (Was: Caching by Postgres)  (Jignesh Shah <J.K.Shah@Sun.COM>)
Ответы Re: Read/Write block sizes (Was: Caching by Postgres)  ("Jeffrey W. Baker" <jwbaker@acm.org>)
Список pgsql-performance
On Tue, Aug 23, 2005 at 05:29:01PM -0400, Jignesh Shah wrote:
>Actually some of that readaheads,etc  the OS does  already if it does
>some sort of throttling/clubbing of reads/writes.

Note that I specified the fully cached case--even with the workload in
RAM the system still has to process a heck of a lot of read calls.

>* Introduce a multiblock or extent tunable variable where you can
>define a multiple of 8K (or BlockSize tuneable) to read a bigger chunk
>and store it in the bufferpool.. (Maybe writes too) (Most devices now
>support upto 1MB chunks for reads and writes)

Yeah. The problem with relying on OS readahead is that the OS doesn't
know whether you're doing a sequential scan or an index scan; if you
have the OS agressively readahead you'll kill your seek performance.
OTOH, if you don't do readaheads you'll kill your sequential scan
performance. At the app level you know which makes sense for each
operation.

Mike Stone

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

Предыдущее
От: Chris Browne
Дата:
Сообщение: Re: Read/Write block sizes
Следующее
От: Michael Stone
Дата:
Сообщение: Re: Read/Write block sizes