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: | Raw Message | Whole Thread | 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 |