Re: WIP: WAL prefetch (another approach) - Mailing list pgsql-hackers

From SATYANARAYANA NARLAPURAM
Subject Re: WIP: WAL prefetch (another approach)
Date
Msg-id CAHg+QDdokr2ifE4m5on=ynLX+5gs=sTu5q67JWKw0=qDjLWrMQ@mail.gmail.com
Whole thread Raw
In response to Re: WIP: WAL prefetch (another approach)  (Simon Riggs <simon.riggs@enterprisedb.com>)
List pgsql-hackers

Other way around. FPWs make prefetch unnecessary.
Therefore you would only want prefetch with FPW=off, AFAIK.
A few scenarios I can imagine page prefetch can help are, 1/ A DR replica instance that is smaller instance size than primary. Page prefetch can bring the pages back into memory in advance when they are evicted. This speeds up the replay and is cost effective. 2/ Allows larger checkpoint_timeout for the same recovery SLA and perhaps improved performance? 3/ WAL prefetch (not pages by itself) can improve replay by itself (not sure if it was measured in isolation, Tomas V can comment on it). 4/ Read replica running analytical workload scenario Tomas V mentioned earlier.
 

Or put this another way: when is it safe and sensible to use
recovery_prefetch != off?
When checkpoint_timeout is set large and under heavy write activity, on a read replica that has working set higher than the memory and receiving constant updates from primary. This covers 1 & 4 above.


--
Simon Riggs                http://www.EnterpriseDB.com/


pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: make MaxBackends available in _PG_init
Next
From: Peter Eisentraut
Date:
Subject: Re: Frontend error logging style