Greg Smith wrote:
On Fri, 15 Feb 2008, Peter Schuller wrote:
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?
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. Another is that shared_buffers memory
has to be reconciled with disk at every checkpoint, where OS buffers
do not. A third is that your OS may just be more efficient at
buffering--it knows more about the underlying hardware, and the
clock-sweep method used internally by PostgreSQL to simulate a LRU
cache is not extremely sophisticated.
However, don't feel limited by the general 25% rule; it's certainly
worth exploring whether 50% or more works better for your workload.
You'll have to benchmark that yourself though, and I'd suggest using
pg_buffercache:
http://www.postgresql.org/docs/8.3/static/pgbuffercache.html to get an
idea just what the pages are being used for.
As per the test that I have done mostly with forcedirectio on Solaris, I
have seen gains with increasing the buffercache to about somewhere
between 10GB and thats when thing seem to take a turn...
So in my case I am generally comfortable for Postgres to use about
8-10GB beyond which I am cautious.
Also with tests with UFS buffered for table/index and forcedirectio it
seems to perform better with forcedirectio .. However if you do want to
exploit the extra RAM with UFS then you have to do some tunings for UFS
in Solaris.. Now with machines with 32GB becoming common this is
something worth pursuing depending on the storage if it can handle the
directio load or not.
Regards,
Jignesh
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
