Re: WIP: WAL prefetch (another approach)

On 4/12/22 17:46, Simon Riggs wrote:
> On Tue, 12 Apr 2022 at 16:41, Tomas Vondra
> <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>>
>> On 4/12/22 15:58, Simon Riggs wrote:
>>> On Thu, 7 Apr 2022 at 08:46, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>>>
>>>> With that... I've finally pushed the 0002 patch and will be watching
>>>> the build farm.
>>>
>>> This is a nice feature if it is safe to turn off full_page_writes.
>>>
>>> When is it safe to do that? On which platform?
>>>
>>> I am not aware of any released software that allows full_page_writes
>>> to be safely disabled. Perhaps something has been released recently
>>> that allows this? I think we have substantial documentation about
>>> safety of other settings, so we should carefully document things here
>>> also.
>>>
>>
>> I don't see why/how would an async prefetch make FPW unnecessary. Did
>> anyone claim that be the case?
>
> Other way around. FPWs make prefetch unnecessary.
> Therefore you would only want prefetch with FPW=off, AFAIK.
>
> Or put this another way: when is it safe and sensible to use
> recovery_prefetch != off?
>

That assumes the FPI stays in memory until the next modification, and
that can be untrue for a number of reasons. Long checkpoint interval
with enough random accesses in between is a nice example. See the
benchmarks I did a year ago (regular pgbench).

Or imagine a r/o replica used to run analytics queries, that access so
much data it evicts the buffers initialized by the FPI records.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company