Dan Scales <sca...@vmware.com> wrote: > The second set of numbers is for a hard disk with write cache > turned off, closer to internal hard disks of servers (people were > quite interested in that result). These runs are for 50-warehouse > 8-processor DBT2 60-minute run, with checkpoints every 5 minutes. > The RAM size is 8G, and the cache size is 6G. > > 9.2 + DW patch > ----------------------------------- > FPW off FPW on DW on/FPW off > CK on CK on CK on > one disk: 12084 7849 9766 [6G shared_buffers, 8G RAM] > > So, here we see a performance advantage for double writes where > the cache is large and the disks do not have write-caching. > Presumably, the cost of fsyncing the big writes (with full pages) > to the WAL log on a slow disk are traded against the fsyncs of the > double writes. I'm very curious about what impact DW would have on big servers with write-back cache that becomes saturated, like in Greg Smith's post here: http://archives.postgresql.org/pgsql-hackers/2012-01/msg00883.php This is a very different approach from what has been tried so far to address that issue, but when I look at the dynamics of that situation, I can't help thinking that DW is the most promising approached for improving that which I've seen suggested so far. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
