From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | david(at)lang(dot)hm |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Ron <rjpeace(at)earthlink(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: understanding postgres issues/bottlenecks |
Date: | 2009-01-10 19:00:59 |
Message-ID: | 4968F06B.1020601@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
david(at)lang(dot)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).
A battery backed cache could theoretically flatten those, as long as
your avg. WAL throughput is below the SSDs avg. writing throughput.
Regards
Markus Wanner
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2009-01-10 19:10:44 | Re: understanding postgres issues/bottlenecks |
Previous Message | Markus Wanner | 2009-01-10 18:45:23 | block device benchmarking |