Re: WAL prefetch

Greetings,

* Tomas Vondra (tomas.vondra@2ndquadrant.com) wrote:
> On 06/16/2018 12:06 PM, Thomas Munro wrote:
> >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
prefetchinginto page 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.
> >
>
> Sure. Assuming the switch to direct I/O will happen (it probably will,
> sooner or later), my question is whether this patch should be required to
> introduce the prefetching into s_b. Or should we use posix_fadvise for now,
> get most of the benefit, and leave the prefetch into s_b as an improvement
> for later?
>
> The thing is - we're already doing posix_fadvise prefetching in bitmap heap
> scans, it would not be putting additional burden on the direct I/O patch
> (hypothetical, so far).

This was my take on it also.  Prefetching is something we've come to
accept in other parts of the system and if it's beneficial to add it
here then we should certainly do so and it seems like it'd keep the
patch nice and simple and small.

Thanks!

Stephen