Re: Asynchronous I/O Support

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Re: Asynchronous I/O Support
Дата
Msg-id 4535D1FD.9090600@paradise.net.nz
обсуждение исходный текст
Ответ на Re: Asynchronous I/O Support  (NikhilS <nikkhils@gmail.com>)
Ответы Re: Asynchronous I/O Support  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
NikhilS wrote:
> Hi,
> 
> "bgwriter doing aysncronous I/O for the dirty buffers that it is 
> supposed to sync"
> Another decent use-case?
> 
> Regards,
> Nikhils
> EnterpriseDB   http://www.enterprisedb.com
> 
> On 10/15/06, *Luke Lonergan* <llonergan@greenplum.com 
> <mailto:llonergan@greenplum.com>> wrote:
> 
>     Martijn,
> 
>     On 10/15/06 10:56 AM, "Martijn van Oosterhout" <kleptog@svana.org
>     <mailto:kleptog@svana.org>> wrote:
> 
>      > Have enough systems actually got to the point of actually supporting
>      > async I/O that it's worth implementing?
> 
>     I think there are enough high end applications / systems that need it at
>     this point.
> 
>     The killer use-case we've identified is for the scattered I/O
>     associated
>     with index + heap scans in Postgres.  If we can issue ~5-15 I/Os in
>     advance
>     when the TIDs are widely separated it has the potential to increase
>     the I/O
>     speed by the number of disks in the tablespace being scanned.  At this
>     point, that pattern will only use one disk.
> 

Is it worth considering using readv(2) instead?

Cheers

Mark


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

Предыдущее
От: NikhilS
Дата:
Сообщение: Re: Asynchronous I/O Support
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: [GENERAL] query log corrupted-looking entries