Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: This is a digitally signed message part.


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux