Re: WAL prefetch

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Sean Chittenden <seanc(at)joyent(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, sean(at)chittenden(dot)org
Subject: Re: WAL prefetch
Date: 2018-07-09 18:28:48
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-07-09 18:28:55 Re: Proposed fix for Bug #15259 (invalid empty array returned by intarray "&" operator)
Previous Message Alvaro Herrera 2018-07-09 18:24:33 Re: pgsql: Add wait event for fsync of WAL segments