> 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@xxxxxxxxxxxx>' Key retrieval: Send an E-Mail to getpgpkey@xxxxxxxxx E-Mail: peter.schuller@xxxxxxxxxxxx Web: http://www.scode.org
Attachment:
pgpntj39I3dlH.pgp
Description: PGP signature
