From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | "Sam R(dot)" <samruohola(at)yahoo(dot)com> |
Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
Subject: | Re: To keep indexes in memory, is large enough effective_cache_size enough? |
Date: | 2018-09-19 10:11:08 |
Message-ID: | CAKJS1f_rMSNu2atjj09f6i-GGOavqxKy8F_J5pO2qHDa8+4Mgw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 19 September 2018 at 21:18, Sam R. <samruohola(at)yahoo(dot)com> wrote:
> Ok. So, we should set also shared_buffers big.
It might not be quite as beneficial as you might think. If your
database is larger than RAM often having a smaller shared_buffers
setting yields better performance. The reason is that if you have a
very large shared_buffers that the same buffers can end up cached in
the kernel page cache and shared buffers. If you have a smaller shared
buffers setting then the chances of that double buffering are reduced
and the chances of finding a page cached somewhere increases.
However, if your database is quite small and you can afford to fit all
your data in shared buffers, with enough free RAM for everything else,
then you might benefit from a large shared buffers, but it's important
to also consider that some operations, such as DROP TABLE can become
slow of shared buffers is very large.
You might get more specific recommendations if you mention how much
RAM the server has and how big the data is now and will be in the
future.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Kaixi Luo | 2018-09-19 10:12:35 | Re: To keep indexes in memory, is large enough effective_cache_size enough? |
Previous Message | Sam R. | 2018-09-19 09:18:24 | Re: To keep indexes in memory, is large enough effective_cache_size enough? |