| 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 |
| Message-ID: | 20180709182848.jirhtmuvcochkrk5@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| 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 |