> PostgreSQL still depends on the OS for file access and caching. I
> think that the current recommendation is to have up to 25% of your
> RAM in the shared buffer cache.
This feels strange. Given a reasonable amount of RAM (let's say 8 GB
in this case), I cannot imagine why 75% of that would be efficiently
used for anything but the buffer cache (ignoring work_mem, stacks,
etc). Obviously the OS will need memory to do it's usual stuff
(buffering to do efficient I/O, and so on). But the need for that
should not increase with the amount of RAM in the machine, all else
being equal.
What type of file I/O, other than reading pages of PostgreSQL data
which are eligable for the PostgreSQL buffer cache, does PostgreSQL do
that would take advantage of the operating system caching so much
data?
(Assuming the database is not extreme to the point of file system meta
data being huge.)
If the 25% rule still holds true, even under circumstances where the
assumption is that the PostgreSQL buffer cache is more efficient (in
terms of hit ratio) at caching PostgreSQL database data pages, it
would be useful to understand why in order to understand the
trade-offs involved and make appropriate decisions.
Or is it a matter of PostgreSQL doing non-direct I/O, such that
anything cached in shared_buffers will also be cached by the OS?
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org
