Re: understanding postgres issues/bottlenecks

Ron 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.
> Yes, Greg understands what I meant here.  In the case of SSDs, the
> performance hit of fsync = on is essentially zero.  In the case of
> battery backed RAM caches for RAID arrays, the efficacy is dependent
> on how the size of the cache compares with the working set of the disk
> access pattern.
Out of interest, if we take a scenario where the working set of updates
exceeds the size
of the RAID card cache, has anyone tested the relative performance of
using the battery
backed RAID on WAL only and non-cached access to other drives?

And perhaps the similar scenario with (hot) indices and WAL on a
battery-backed device
on the data on uncached devices?

It seems to me that if you're going to thrash the cache from data
updates (presumably
courtesy of full-page-write), then you might be better to partition the
cache - and a
thrashed cache can be hardly any better than no cache (so why have one?).