Re: WAL prefetch

On 06/16/2018 12:06 PM, Thomas Munro wrote:
> On Sat, Jun 16, 2018 at 9:38 PM, Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)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 into 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).

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services