Well for one thing on the IODrive. Be sure to use a FS that supports direct IO so you don't cache it on the FS level and thus take room an object not on SSD could use. We use vxfs with mincache=direct as our filesystem for just this reason. Also, there is an IO drive tuning manual that discusses the same. It's a good read if you don't already have it. I do not know of a way to partition the PG cache other than make it small and use the FS controls to force direct IO.
2.5 cents.. -kg -----Original Message----- From: pgsql-performance-ow...@postgresql.org on behalf of Shaul Dar Sent: Mon 5/25/2009 6:51 AM To: pgsql-performance@postgresql.org Subject: [PERFORM] Putting tables or indexes in SSD or RAM: avoiding double caching? Hi, I have sen many posts on using SSDs, and iodrive <http://www.fusionio.com>in particular, to accelerate the performance of Postgresql (or other DBMS) -- e.g. this discussion<http://groups.google.co.il/group/pgsql.performance/browse_thread/thread/1d6d7434246afd97?pli=1>. I have also seen the suggestion to use RAM for the same purpose by creating a tablespace on a RAM mount point.<http://magazine.redhat.com/2007/12/12/tip-from-an-rhce-memory-storage-on-postgresql/>Granted these make most sense when the whole database cannot fit into main memory, or if we want to avoid cold DB response times (i.e waiting for the DB to "warm up" as stuff gets cached in memory). My question is this: if we use either SSD or RAM tablespaces, I would imagine postgresql will be oblevient to this and would still cache the tablespace elemenst that are on SSD or RAM into memory - right? Is there a way to avoid that, i.e. to tell postgress NOT to cache tablespaces, or some other granularity of the DB? Thanks, -- Shaul *Dr. Shaul Dar* Email: i...@shauldar.com Web: www.shauldar.com
