Re: Performance Tuning Document?

----- Original Message -----
From: "Steve Wolfe"

>
> Yes. Huge, raging amounts of shared buffers do have the consequence of
> diminishing your disk cache size. You want to make sure that you can
> always keep the *entire* database in disk cache, or you end up taking a
> performance hit by having to read from disk, in the same spirit of keeping
> your machine from swapping.
>

if u imply that you'd better leave huge amounts of memory to the OS buffer
cache rather than give them to the DB buffer cache then I strongly disagree.

To name two important issues:

- the OS block size may be different from the DB block size (which is
especially true for Postgres where if I'm not mistaken the DB block is fixed
to 8KB).
You want to keep DB blocks in memory regardless of the fact if the relevant
OS blocks are in the OS buffer cache (just consider the cases where the DB
block is larger/smaller than the OS block)

- the OS buffer cache is designed to satisfy all different kinds of
processes while the DB buffer cache is designed to suit only the database,
so it should suit it better.
For example (some day) you may have multiple buffer caches with different
queue strategies (just like the KEEP and RECYCLE buffer pools in Oracle)
while the OS will give you only LRU queuing

A good on-topic reading is "Avoid Buffered I/O" by Steve Adams available at
http://www.ixora.com.au/tips/avoid_buffered_io.htm

also, I don't want to "always keep the *entire* database in disk cache" - I
want to keep cached only the frequently accessed parts of the data

Marin

----
"...what you brought from your past, is of no use in your present. When
you must choose a new path, do not bring old experiences with you.
Those who strike out afresh, but who attempt to retain a little of the
old life, end up torn apart by their own memories. "