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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
