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