On Fri, Nov 20, 2009 at 7:27 PM, Greg Smith <g...@2ndquadrant.com> wrote: > Richard Neill wrote: >> >> The key issue for short,fast transactions seems to be >> how fast an fdatasync() call can run, forcing the commit to disk, and >> allowing the transaction to return to userspace. >> Attached is a short C program which may be of use. > > Right. I call this the "commit rate" of the storage, and on traditional > spinning disks it's slightly below the rotation speed of the media (i.e. > 7200RPM = 120 commits/second). If you've got a battery-backed cache in > front of standard disks, you can easily clear 10K commits/second.
...until you overflow the cache. battery backed cache does not break the laws of physics...it just provides a higher burst rate (plus what ever advantages can be gained by peeking into the write queue and re-arranging/grouping. I learned the hard way that how your raid controller behaves in overflow situations can cause catastrophic performance degradations... merlin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
