> > >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 the page cache. > The amount of data read may be decreased by the kernel depending > on VM load. (A few megabytes will usually 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.
POSIX_FADV_WILLNEED definitely sounds very interesting, but: I think this interface was intended to hint larger areas (megabytes). But the "wishful" thinking was not to hint seq scans, but to advise single 8k pages. The OS is responsible for sequential readahead, but it cannot anticipate random access that results from btree access (unless of course we are talking about very small tables). But I doubt, that with this interface many OS's will actually forward multiple IO's to the disk subsystem in parallel, which would be what is needed. Also the comment Bruce quoted does not sound incouraging :-( Andreas ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly