| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WIP: WAL prefetch (another approach) |
| Date: | 2020-12-04 19:01:45 |
| Message-ID: | 20201204190145.GW16415@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greetings,
* Andres Freund (andres(at)anarazel(dot)de) wrote:
> On 2020-12-04 13:27:38 -0500, Stephen Frost wrote:
> > If I follow correctly, this patch will scan ahead in the WAL and let
> > the kernel know that certain blocks will be needed soon. Ideally,
> > though I don't think it does yet, we'd only do that for blocks that
> > aren't already in shared buffers, and only for non-FPIs (even better if
> > we can skip past pages for which we already, recently, passed an FPI).
>
> The patch uses PrefetchSharedBuffer(), which only initiates a prefetch
> if the page isn't already in s_b.
Great, glad that's already been addressed in this, that's certainly
good. I think I knew that and forgot it while composing that response
over the past rather busy week. :)
> And once we have AIO, it can actually initiate IO into s_b at that
> point, rather than fetching it just into the kernel page cache.
Sure.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2020-12-04 19:14:28 | Re: Add docs stub for recovery.conf |
| Previous Message | Stephen Frost | 2020-12-04 19:00:23 | Re: Add docs stub for recovery.conf |