Re: WAL prefetch

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.