From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | tfoertsch123(at)gmail(dot)com, Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Is there a way to speed up WAL replay? |
Date: | 2018-10-31 15:32:53 |
Message-ID: | 20181031153252.GY4184@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Greetings,
* Jeff Janes (jeff(dot)janes(at)gmail(dot)com) wrote:
> One way I found to speed up restore_command is to have another program run
> a few WAL files ahead of it, copying the WAL from the real archive into a
> scratch space which is on the same filesystem as pg_xlog/pg_wal. Then have
> restore_command simply move (not copy) the requested files from the scratch
> space onto %p. The intra-filesystem move completes much faster than a copy.
Right, that can definitely be a big help and is more-or-less what
pgbackrest does too.
> If it spends time waiting for blocks that need to be recovered into to get
> read from disk, and you have enough RAM, you could speed it up by
> pre-warming the file system cache. Something like:
>
> tar -cf - $PGDATA | wc -c
Yeah, that's also a good idea. We've discussed having something in
pgbackrest to basically go pre-load things off disk in advance of WAL
replay, and I seem to recall someone had also written an external tool
to do that.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolas Grilly | 2018-10-31 15:35:49 | Re: Is there a way to speed up WAL replay? |
Previous Message | Stephen Frost | 2018-10-31 15:30:49 | Re: Is there a way to speed up WAL replay? |