Re: WAL prefetch - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: WAL prefetch
Date
Msg-id CAEepm=3+uKBaDLgWivx9zt2-k6rr4WrVYQCK0N1+aaLrB+ZxRA@mail.gmail.com
Whole thread Raw
In response to Re: WAL prefetch  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: WAL prefetch
List pgsql-hackers
On Sat, Jun 16, 2018 at 9:38 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> On 06/15/2018 08:01 PM, Andres Freund wrote:
>> On 2018-06-14 10:13:44 +0300, Konstantin Knizhnik wrote:
>>> On 14.06.2018 09:52, Thomas Munro wrote:
>>>> Why stop at the page cache...  what about shared buffers?
>>>
>>> It is good question. I thought a lot about prefetching directly to shared
>>> buffers.
>>
>> I think that's definitely how this should work.  I'm pretty strongly
>> opposed to a prefetching implementation that doesn't read into s_b.
>
> Could you elaborate why prefetching into s_b is so much better (I'm sure it has advantages, but I suppose prefetching
intopage cache would be much easier to implement).
 

posix_fadvise(POSIX_FADV_WILLNEED) might already get most of the
speed-up available here in the short term for this immediate
application, but in the long term a shared buffers prefetch system is
one of the components we'll need to support direct IO.

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: WAL prefetch
Next
From: Tomas Vondra
Date:
Subject: Re: WAL prefetch