> PostgreSQL only uses direct I/O for writing to the WAL; everything else
> goes through the regular OS buffer cache unless you force it to do
> otherwise at the OS level (like some Solaris setups do with
> forcedirectio). This is one reason it still make not make sense to give
> an extremely high percentage of RAM to PostgreSQL even with improvements
> in managing it.
Ok - thank you for the input (that goes for everyone).
> Another is that shared_buffers memory has to be
> reconciled with disk at every checkpoint, where OS buffers do not.
Hmm. Am I interpreting that correctly in that dirty buffers need to be flushed
to disk at checkpoints? That makes perfect sense - but why would that not be
the case with OS buffers? My understanding is that the point of the
checkpoint is to essentially obsolete old WAL data in order to recycle the
space, which would require flushing the data in question first (i.e.,
normally you just fsync the WAL, but when you want to recycle space you need
fsync() for the barrier and are then free to nuke the old WAL).
--
/ 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
