Message-ID: <3f4d65c8-ad61-9f57-d5ad-6c1ea841e471@enterprisedb.com>
Date: Tue, 12 Apr 2022 18:07:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: WIP: WAL prefetch (another approach)
Content-Language: en-US
To: Simon Riggs <simon.riggs@enterprisedb.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, Julien Rouhaud
 <rjuju123@gmail.com>, Ashutosh Sharma <ashu.coek88@gmail.com>,
 Daniel Gustafsson <daniel@yesql.se>, Stephen Frost <sfrost@snowman.net>,
 Alvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund
 <andres@anarazel.de>, David Steele <david@pgmasters.net>,
 Dmitry Dolgov <9erthalion6@gmail.com>, Jakub Wartak
 <Jakub.Wartak@tomtom.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: 
 <CA+hUKG+dE2-BOsZAQJC4miaXhZF3U6WV0cUH6yWJ+ixoiFNOSw@mail.gmail.com>
 <20220309064633.woyf53w3odnhltah@jrouhaud>
 <CA+hUKGKusWunqOd9En+FkT+US_kuDK-MSZyXHCr=OTwRw8Ah1A@mail.gmail.com>
 <20220311082737.bmnlmtzwi2xqrhxl@jrouhaud>
 <CA+hUKGKBxHZMVJFELZhC8iD57TBhboHtpmG+rzdOSdRGyxUGeQ@mail.gmail.com>
 <20220314071713.v4anmngdi5njaple@jrouhaud>
 <CA+hUKG+0Qe2b7eFancRmZcq1wAsFGizFVuq9bSAg5uNy+4wMiQ@mail.gmail.com>
 <CA+hUKGL=R4MMEX7DtFefnnT6v5Dun=Y=OWLCgD0_ixK2KkkKRw@mail.gmail.com>
 <20220321082916.ysrlw2xst2tpyc5a@jrouhaud>
 <CA+hUKGKs7cNkiMyNY9aSn2bF2AQNj9bb_dbY2B_6d_srnx5+mw@mail.gmail.com>
 <YkpiH3sFL8XsPBgs@jrouhaud>
 <CA+hUKGJ3aq3ZAxfhuPvMkOKwirfqunrV-p8d7kEe_WunjGndDw@mail.gmail.com>
 <CANbhV-FsVOXou11teGwPWiHh__yaDUSTG6K2JPRTHgznt2uvpg@mail.gmail.com>
 <03cf0942-662b-8ef5-90e4-b8182f2e1b8d@enterprisedb.com>
 <CANbhV-EVrOSZqk0MofgZa1xqNmFgXwFaC6JyvBfDR+stqzAfLQ@mail.gmail.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: 
 <CANbhV-EVrOSZqk0MofgZa1xqNmFgXwFaC6JyvBfDR+stqzAfLQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/3f4d65c8-ad61-9f57-d5ad-6c1ea841e471%40enterprisedb.com>
Precedence: bulk

On 4/12/22 17:46, Simon Riggs wrote:
> On Tue, 12 Apr 2022 at 16:41, Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
>>
>> On 4/12/22 15:58, Simon Riggs wrote:
>>> On Thu, 7 Apr 2022 at 08:46, Thomas Munro <thomas.munro@gmail.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