Skip site navigation (1) Skip section navigation (2)


From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>
Cc: Karl Denninger <karl(at)denninger(dot)net>, Laszlo Nagy <gandalf(at)shopzeus(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: SSD + RAID
Date: 2009-11-13 21:06:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Brad Nicholson wrote:
> Out of curiosity, what are those narrow use cases where you think 
> SSD's are the correct technology?
Dave Crooke did a good summary already, I see things like this:

 * You need to have a read-heavy app that's bigger than RAM, but not too 
big so it can still fit on SSD
 * You need reads to be dominated by random-access and uncached lookups, 
so that system RAM used as a buffer cache doesn't help you much.
 * Writes have to be low to moderate, as the true write speed is much 
lower for database use than you'd expect from benchmarks derived from 
other apps.  And it's better if writes are biased toward adding data 
rather than changing existing pages

As far as what real-world apps have that profile, I like SSDs for small 
to medium web applications that have to be responsive, where the user 
shows up and wants their randomly distributed and uncached data with 
minimal latency. 

SSDs can also be used effectively as second-tier targeted storage for 
things that have a performance-critical but small and random bit as part 
of a larger design that doesn't have those characteristics; putting 
indexes on SSD can work out well for example (and there the write 
durability stuff isn't quite as critical, as you can always drop an 
index and rebuild if it gets corrupted).

Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support

In response to


pgsql-performance by date

Next:From: Merlin MoncureDate: 2009-11-13 21:09:18
Subject: Re: SSD + RAID
Previous:From: Robert HaasDate: 2009-11-13 21:05:38
Subject: Re: Why age (datfrozenxid) in postgres becomes 1073742202 not zero after each vacuum of database.

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group