Re: Shared Memory Sizing

On Fri, 28 Jun 2002, Bruce Momjian wrote:

> You have the block in the kernel buffer when you copy it to the
> PostgreSQL buffers, but nothing says you have to keep that block in the
> kernel buffers while PostgreSQL has it.  Only when it is written does it
> return to the kernel, and if it is only read, it never returns to the
> kernel.

Sure. But the OS doesn't know that after you read a block it may
immediately abandon buffering of that block. It's going to use the
same strategy it does for any other block, which is to keep it in
memory for a while, preferring to get rid of older blocks.

If you had a way to tell the OS, "I'm buffering block X, so you
don't need to" that would be one thing. But you don't.

> > For most workloads, in the long run, that will force you to do disk
> > I/O that you would not have had to do otherwise. A single disk I/O
> > is far more expensive than hundreds of copies between the OS buffer
> > cache and postgres' shared memory.
>
> Yes, if you swap, you went too far.  That has always been the upper
> limit.

Not just swap: disk I/O for blocks that would have been buffered
by the OS if you hadn't been using memory that it could use.

cjs
--
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC