Re: understanding postgres issues/bottlenecks - Mailing list pgsql-performance

From david@lang.hm
Subject Re: understanding postgres issues/bottlenecks
Date
Msg-id alpine.DEB.1.10.0901101140370.31038@asgard.lang.hm
Whole thread Raw
In response to Re: understanding postgres issues/bottlenecks  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: understanding postgres issues/bottlenecks  (Markus Wanner <markus@bluegap.ch>)
List pgsql-performance
On Sat, 10 Jan 2009, Gregory Stark wrote:

>>> ...and of course, those lucky few with bigger budgets can use SSD's and not
>>> care what fsync is set to.
>>
>> Would that prevent any corruption if the writes got out of order
>> because of lack of fsync?  Or partial writes?  Or wouldn't fsync still
>> need to be turned on to keep the data safe.
>
> 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.

I don't think that this is true, even if your SSD is battery backed RAM
(as opposed to the flash based devices that have slower writes than
high-end hard drives) you can complete 'writes' to the system RAM faster
than the OS can get the data to the drive, so if you don't do a fsync you
can still loose a lot in a power outage.

raid controllers with battery backed ram cache will make the fsyncs very
cheap (until the cache fills up anyway)

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.

David Lang

pgsql-performance by date:

Previous
From: Markus Wanner
Date:
Subject: block device benchmarking
Next
From: Markus Wanner
Date:
Subject: Re: understanding postgres issues/bottlenecks