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

From: Shaul Dar <shauldar(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Putting tables or indexes in SSD or RAM: avoiding double caching?
Date: 2009-05-25 13:51:59
Message-ID: 234efe30905250651i67b86882q3d9eaa91d1432c01@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message David Blewett 2009-05-25 15:22:38 Re: Bad Plan for Questionnaire-Type Query
Previous Message Łukasz Jagiełło 2009-05-24 19:46:38 Problems with autovacuum