Re: [SPAM?] Re: Asynchronous I/O Support

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: [SPAM?] Re: Asynchronous I/O Support
Дата
Msg-id 20061020191030.GC31471@svana.org
обсуждение исходный текст
Ответ на Re: [SPAM?] Re: Asynchronous I/O Support  ("Merlin Moncure" <mmoncure@gmail.com>)
Ответы Re: [SPAM?] Re: Asynchronous I/O Support  ("Merlin Moncure" <mmoncure@gmail.com>)
Re: [SPAM?] Re: Asynchronous I/O Support  (Bruce Momjian <bruce@momjian.us>)
Re: [SPAM?] Re: Asynchronous I/O Support  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
Список pgsql-hackers
On Fri, Oct 20, 2006 at 03:04:55PM -0400, Merlin Moncure wrote:
> On 10/20/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >So far I've seen no evidence that async I/O would help us, only a lot
> >of wishful thinking.
>
> is this thread moot?  while researching this thread I came across this
> article: http://kerneltrap.org/node/6642 describing claims of 30%
> performance boost when using posix_fadvise to ask the o/s to prefetch
> data.  istm that this kind of improvement is in line with what aio can
> provide, and posix_fadvise is cleaner, not requiring threads and such.

Hmm, my man page says:
      POSIX_FADV_WILLNEED and POSIX_FADV_NOREUSE both initiate a      non-blocking read of the specified region into
thepage cache.       The amount of data read may be decreased by the kernel depending      on VM load. (A few megabytes
willusually be fully satisfied,      and more is rarely useful.) 

This appears to be exactly what we want, no? It would be nice to get
some idea of what systems support this.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

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

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: [SPAM?] Re: Asynchronous I/O Support
Следующее
От: Andreas Seltenreich
Дата:
Сообщение: Re: backup + restore fails