Re: SSD Drives - Mailing list pgsql-general

From Steve Crawford
Subject Re: SSD Drives
Date
Msg-id 533ED7F1.20903@pinpointresearch.com
Whole thread Raw
In response to Re: SSD Drives  (Brent Wood <Brent.Wood@niwa.co.nz>)
Responses Re: SSD Drives
Re: SSD Drives
List pgsql-general
On 04/03/2014 12:44 PM, Brent Wood wrote:
P.ImprintUniqueID {MARGIN: 0cm 0cm 0pt } LI.ImprintUniqueID {MARGIN: 0cm 0cm 0pt } DIV.ImprintUniqueID {MARGIN: 0cm 0cm 0pt } TABLE.ImprintUniqueIDTable {MARGIN: 0cm 0cm 0pt } DIV.Section1 {page: Section1 } .ExternalClass * {LINE-HEIGHT: 100% }
Hi David,

Does the RAID 1 array give any performance benefits over a single drive? I'd guess that writes may be slower, reads may be faster (if balanced) but data security is improved.

I've been looking into upgrading to SSD and wondering about RAID and where to apply $$$ as well. In particular I'm curious about any real-world PostgreSQL-oriented performance and data-protections advice in the following areas:

1. With SSDs being orders of magnitude faster than spinning media, when does the RAID controller rather than the storage become the bottleneck?

2. Do I need both BBU on the RAID *and* capacitor on the SSD or just on one? Which one? I'm suspecting capacitor on the SSD and write-through on the RAID.

2. Current thoughts on hardware vs. software RAID - especially since many of the current SSD solutions plug straight into the bus.

3. Potential issues or conflicts with SSD-specific requirements like TRIM.

4. Manufacturers, models or technologies to seek out or avoid.

5. At what point do we consider the RAID controller an additional SPOF that decreases instead of increases reliability?

6. Thoughts on "best bang for the buck?" For example, am I better off dropping the RAID cards and additional drives and instead adding another standby server?

Cheers,
Steve

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why is pg_restore trying to create tables in pg_catalog?
Next
From: David Boreham
Date:
Subject: Re: SSD Drives