| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| 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 18:51:57 |
| Message-ID: | 20201204185157.w3qtqyym6fixmnrg@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
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.
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.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2020-12-04 18:57:13 | Re: POC: Better infrastructure for automated testing of concurrency issues |
| Previous Message | Joel Jacobson | 2020-12-04 18:44:37 | Re: [PATCH] Add support for leading/trailing bytea trim()ing |