Re: WIP: WAL prefetch (another approach)

Поиск
Список
Период
Сортировка
От SATYANARAYANA NARLAPURAM
Тема Re: WIP: WAL prefetch (another approach)
Дата
Msg-id CAHg+QDdokr2ifE4m5on=ynLX+5gs=sTu5q67JWKw0=qDjLWrMQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: WAL prefetch (another approach)  (Simon Riggs <simon.riggs@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: make MaxBackends available in _PG_init
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Frontend error logging style