Re: Reduce/eliminate the impact of FPW

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
Cc: Daniel Wood <hexexpert(at)comcast(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reduce/eliminate the impact of FPW
Date: 2020-08-04 13:05:06
Message-ID: 20200804130506.GO12375@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

Please don't top-post on these lists.

* SATYANARAYANA NARLAPURAM (satyanarlapuram(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-08-04 13:31:03 Re: Replace remaining StrNCpy() by strlcpy()
Previous Message Etsuro Fujita 2020-08-04 12:45:31 Yet another issue with step generation in partition pruning