Re: WIP: WAL prefetch (another approach)
От | Thomas Munro |
---|---|
Тема | Re: WIP: WAL prefetch (another approach) |
Дата | |
Msg-id | CA+hUKG+deAXJUigdX4yDqwzWyqr6qLA8StiWJVFOHTy83eqqtA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: WAL prefetch (another approach) (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: WIP: WAL prefetch (another approach)
|
Список | 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 по дате отправления: