From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: WAL prefetch (another approach) |
Date: | 2021-04-09 20:27:42 |
Message-ID: | CA+hUKG+deAXJUigdX4yDqwzWyqr6qLA8StiWJVFOHTy83eqqtA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 9, 2021 at 3:37 PM Justin Pryzby <pryzby(at)telsasoft(dot)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].
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-04-09 20:36:58 | Re: WIP: WAL prefetch (another approach) |
Previous Message | Peter Eisentraut | 2021-04-09 20:02:47 | Re: truncating timestamps on arbitrary intervals |