On Mon, 2005-10-31 at 14:50 -0600, Scott Marlowe wrote:
> As I understand it, when the last backend referencing a collection of
> data stops referencing it, that the buffers holding that data are
> released, and if, a second later, another backend wants the data, then
> it has to go to the Kernel for it again.
Unreferenced data is not immediately released to the kernel. When a
backend requests a datablock that is not in shared_buffers it will
select an unreferenced buffer, write it if required (hopefully not
required because of the bgwriter), then overwrite the shared_buffer
cache with the datablock it is trying to read from "disk". All reads and
writes go through the OS cache, which does pretty much the same thing
but with a different algorithm. So "disk" might just mean OS cache.
There's zero *requirement* for the OS cache to be bigger than
shared_buffers. Martijn and Tom discuss that there are a number of
advantages to not overallocating shared_buffers, which is the reason why
the usual recommendation is to not do that.
Best Regards, Simon Riggs
In response to
pgsql-general by date
|Next:||From: Martijn van Oosterhout||Date: 2005-10-31 21:47:50|
|Subject: Re: Starting PostgreSQL 8.0.4 with more memory [FreeBSD|
|Previous:||From: Alex Turner||Date: 2005-10-31 21:39:18|
|Subject: Re: SQL injection|