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

From Thomas Munro
Subject Re: WIP: WAL prefetch (another approach)
Date
Msg-id CA+hUKG+deAXJUigdX4yDqwzWyqr6qLA8StiWJVFOHTy83eqqtA@mail.gmail.com
Whole thread Raw
In response to Re: WIP: WAL prefetch (another approach)  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: WIP: WAL prefetch (another approach)  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Fri, Apr 9, 2021 at 3:37 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> Here's some little language fixes.

Thanks!  Done.  I rewrote the gibberish comment that made you say
"XXX: what?".  Pushed.

> BTW, before beginning "recovery", PG syncs all the data dirs.
> This can be slow, and it seems like the slowness is frequently due to file
> metadata.  For example, that's an obvious consequence of an OS crash, after
> which the page cache is empty.  I've made a habit of running find /zfs -ls |wc
> to pre-warm it, which can take a little bit, but then the recovery process
> starts moments later.  I don't have any timing measurements, but I expect that
> starting to stat() all data files as soon as possible would be a win.

Did you see commit 61752afb, "Provide
recovery_init_sync_method=syncfs"?  Actually I believe it's safe to
skip that phase completely and do a tiny bit more work during
recovery, which I'd like to work on for v15[1].

[1]
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2B8Wm8TSfMWPteMEHfh194RytVTBNoOkggTQT1p5NTY7Q%40mail.gmail.com



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: truncating timestamps on arbitrary intervals
Next
From: Justin Pryzby
Date:
Subject: Re: WIP: WAL prefetch (another approach)