Re: Read/Write block sizes (Was: Caching by Postgres)
От | Jeffrey W. Baker |
---|---|
Тема | Re: Read/Write block sizes (Was: Caching by Postgres) |
Дата | |
Msg-id | 1124840650.12932.1.camel@toonses.gghcwest.com обсуждение исходный текст |
Ответ на | Re: Read/Write block sizes (Was: Caching by Postgres) (Michael Stone <mstone+postgres@mathom.us>) |
Список | pgsql-performance |
On Tue, 2005-08-23 at 19:12 -0400, Michael Stone wrote: > 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. This is why we have MADVISE_RANDOM and MADVISE_SEQUENTIAL. -jwb
В списке pgsql-performance по дате отправления: