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

From: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, <mark(at)mark(dot)mielke(dot)cc>, "NikhilS" <nikkhils(at)gmail(dot)com>, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "Luke Lonergan" <llonergan(at)greenplum(dot)com>, "Raja Agrawal" <raja(dot)agrawal(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [SPAM?] Re: Asynchronous I/O Support
Date: 2006-10-23 07:47:14
Message-ID: E1539E0ED7043848906A8FF995BDA5790172648F@m0143.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > 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.

This again is for better OS readahead for sequential access, where
standard Linux obviously behaves differently. It is not about random
access.

Btw. I do understand the opinion from Linux developers, that pg should
actually
read larger blocks for seq scans. In cases of high disk load OS's tend
to not
do all needed readahead, which has pros and cons, but mainly cons for
pg.

Andreas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas ADI SD 2006-10-23 07:59:30 Re: [SPAM?] Re: Asynchronous I/O Support
Previous Message Zeugswetter Andreas ADI SD 2006-10-23 07:38:08 Re: [SPAM?] Re: Asynchronous I/O Support