On 09.07.2018 21:28, Andres Freund wrote:
Hi,
On 2018-07-09 11:59:06 +0200, Tomas Vondra wrote:
* During the design phase, I looked into using bgworkers but given the number of
in-flight pread(2) calls required to fully utilize the IO subsystem, I opted
for something threaded (I was also confined to using Solaris which doesn't
support posix_fadvise(2), so I couldn't sequentially dispatch async
posix_fadvise(2) calls and hope for the best).
Hmm, yeah. I'm not sure what to do with this. Using many (thousands?) of
prefetch processes seems like a bad idea - we surely can't make them regular
bgworkers. Perhaps we could use one process with many threads?
Presumably if we knew about a better way to do prefetching without
posix_fadvise, we'd have implemented it in FilePrefetch(). But we just error
out instead :-(
Solaris is dead. We shouldn't design for it... I think there's decent
reasons to go for a non fadvise approach, but solaris imo isn't one of
them.
Greetings,
Andres Freund
I have attached to the first my mail in this thread small utility for
measuring effect of data prefetch for random reads.
At my desktop posix_fadvise performed in one thread demostrated the best
results, comparing with pread in any number of threads.
