Re: Reduce/eliminate the impact of FPW

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Reduce/eliminate the impact of FPW
Дата
Msg-id 20200804130506.GO12375@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Reduce/eliminate the impact of FPW  (SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>)
Список pgsql-hackers
Greetings,

Please don't top-post on these lists.

* SATYANARAYANA NARLAPURAM (satyanarlapuram@gmail.com) wrote:
> Increasing checkpoint_timeout helps reduce the amount of log written to the
> disk. This has several benefits like, reduced number of WAL IO, archival
> load on the system, less network traffic to the standby replicas. However,
> this increases the crash recovery time and impact server availability.

Sure.

> Investing in parallel recovery for Postgres helps reduce the crash recovery
> time and allows us to change the checkpoint frequency to much higher value?

Parallel recovery is a nice idea but it's pretty far from trivial..  Did
you have thoughts about how that would be accomplished?

> This idea is orthogonal to the double write improvements mentioned in the
> thread. Thomas Munro has a patch of doing page prefetching during recovery
> which speeds up recovery if the working set doesn't fit in the memory, we
> also need parallel recovery to replay huge amounts of WAL, when the working
> set is in memory.

What OS, filesystem, etc, are you running where you're seeing that the
WAL pre-fetch is helping to speed up recovery?  Based on prior
discussion, that seemed to help primarily on ZFS due to the block size
being larger than our block size, which, while somewhat interesting,
isn't as exciting as finding a way to speed up recovery across the
board.

Thanks,

Stephen

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Yet another issue with step generation in partition pruning
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Replace remaining StrNCpy() by strlcpy()