On Mon, 2005-10-31 at 15:44, Simon Riggs wrote: > 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. Hence the reason I carefully hedged my reference as "getting it from the kernel." I wasn't really wanting to discuss how the kernel manages to make it magically appear, as it's the kernel's job to do it and keep track of it. The point behind my post was that the kernel caches AND buffers, while postgresql technically only really seems to buffer, with a little incidental caching thrown in if you catch it at the right time. I was mainly wondering if that behaviour had changed, if, when the data are released, they are still held in shared memory until forced out by newer / more popular data. Which would make the buffer pool a real cache. As long as postgresql releases hold on all those buffers when they're not needed, I would think it was a buffer, not a real cache, and it shouldn't normally be tuned as a cache. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
