Re: Putting tables or indexes in SSD or RAM: avoiding double caching?

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-owner(at)postgresql(dot)org on behalf of Shaul Dar
Sent: Mon 5/25/2009 6:51 AM
To: pgsql-performance(at)postgresql(dot)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: info(at)shauldar(dot)com
Web: www.shauldar.com