Re: SSD + RAID

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Scott Carey <scott(at)richrelevance(dot)com>
Cc: Karl Denninger <karl(at)denninger(dot)net>, Greg Smith <greg(at)2ndquadrant(dot)com>, Laszlo Nagy <gandalf(at)shopzeus(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: SSD + RAID
Date: 2009-11-19 04:24:00
Message-ID: 4847.1258604640@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Scott Carey <scott(at)richrelevance(dot)com> writes:
> For your database DATA disks, leaving the write cache on is 100% acceptable,
> even with power loss, and without a RAID controller. And even in high write
> environments.

Really? How hard have you tested that configuration?

> That is what the XLOG is for, isn't it?

Once we have fsync'd a data change, we discard the relevant XLOG
entries. If the disk hasn't actually put the data on stable storage
before it claims the fsync is done, you're screwed.

XLOG only exists to centralize the writes that have to happen before
a transaction can be reported committed (in particular, to avoid a
lot of random-access writes at commit). It doesn't make any
fundamental change in the rules of the game: a disk that lies about
write complete will still burn you.

In a zero-seek-cost environment I suspect that XLOG wouldn't actually
be all that useful. I gather from what's been said earlier that SSDs
don't fully eliminate random-access penalties, though.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Carey 2009-11-19 04:35:02 Re: SSD + RAID
Previous Message Scott Carey 2009-11-19 04:22:29 Re: SSD + RAID