On Sat, Jan 10, 2009 at 12:00 PM, Markus Wanner <mar...@bluegap.ch> wrote: > Hi, > > da...@lang.hm wrote: >> On Sat, 10 Jan 2009, Gregory Stark wrote: >>> I think the idea is that with SSDs or a RAID with a battery backed >>> cache you >>> can leave fsync on and not have any significant performance hit since >>> the seek >>> times are very fast for SSD. They have limited bandwidth but bandwidth >>> to the >>> WAL is rarely an issue -- just latency. > > That's also my understanding. > >> with SSDs having extremely good read speeds, but poor (at least by >> comparison) write speeds I wonder if any of the RAID controllers are >> going to get a mode where they cache writes, but don't cache reads, >> leaving all ofyour cache to handle writes. > > My understanding of SSDs so far is, that they are not that bad at > writing *on average*, but to perform wear-leveling, they sometimes have > to shuffle around multiple blocks at once. So there are pretty awful > spikes for writing latency (IIRC more than 100ms has been measured on > cheaper disks).
Multiply it by 10 and apply to both reads and writes for most cheap SSDs when doing random writes and reads mixed together. Which is why so many discussions specificall mention the intel XM series, because they don't suck like that. They keep good access times even under several random read / write threads. Some review of the others was posted here a while back and it was astounding how slow the others became in a mixed read / write benchmark. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
