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?).
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
