| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Joao Junior <jcoj2006(at)gmail(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: shared buffers and startup process |
| Date: | 2020-01-15 02:48:00 |
| Message-ID: | 20200115024800.GD2243@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Jan 14, 2020 at 04:29:51PM +0100, Joao Junior wrote:
> I would like to know if increasing the amount of shared-buffers could help
> the startup process applying the wals. I would like to know if in
> the process of reading the wals and applying them, blocks that should be
> written will be brought to shared buffer or not??
Please feel free to look at XLogReadBufferForRedo() in xlogutils.c and
check what the routine does, and when/where it gets called. The code
is well-documented, so you will find your answer easily.
> If yes, having a bigger
> shared buffer will keep as much as possible the amount of pages there and
> increase the startup process's speed avoiding pages's replacement and going
> to the OS cache and maybe to the disk .
> Does it make sense?
It does. Even if relying on the OS cache would be enough in most
cases, it is good to keep a certain of pages hot enough, and you need
to be careful with not setting shared_buffers too high either.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marcin Barczyński | 2020-01-16 13:21:57 | Queries in plpgsql are 6 times slower on partitioned tables |
| Previous Message | Joao Junior | 2020-01-14 15:29:51 | shared buffers and startup process |