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