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.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).

regards

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