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) Michael Stone <mstone+postgres@mathom.us>
Re: Read/Write block sizes (Was: Caching by Postgres) "Jeffrey W. Baker" <jwbaker@acm.org>
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
FAQ