Re: [WIP] Double-write with Fast Checksums - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: [WIP] Double-write with Fast Checksums
Date
Msg-id 4F158A1702000025000448B8@gw.wicourts.gov
Whole thread Raw
In response to Re: [WIP] Double-write with Fast Checksums  (Dan Scales <scales@vmware.com>)
Responses Re: [WIP] Double-write with Fast Checksums  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
Dan Scales <scales@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


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PATCH: tracking temp files in pg_stat_database
Next
From: Martin Pihlak
Date:
Subject: Re: Patch review for logging hooks (CF 2012-01)