Re: WAL prefetch - Mailing list pgsql-hackers

From Andres Freund
Subject Re: WAL prefetch
Date
Msg-id 20180709182848.jirhtmuvcochkrk5@alap3.anarazel.de
Whole thread Raw
In response to Re: WAL prefetch  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: WAL prefetch  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: How can we submit code patches that implement our (pending)patents?
Next
From: Tom Lane
Date:
Subject: Re: Proposed fix for Bug #15259 (invalid empty array returned by intarray "&" operator)