Skip site navigation (1) Skip section navigation (2)

Re: 16-bit page checksums for 9.2

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: 16-bit page checksums for 9.2
Date: 2012-01-10 05:04:40
Message-ID: 4F0BC6E8.3070905@2ndQuadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 12/30/11 9:44 AM, Aidan Van Dyk wrote:

> So moving to this new double-write-area bandwagon, we move from a "WAL
> FPW synced at the commit, collect as many other writes, then final
> sync" type system to a system where *EVERY* write requires syncs of 2
> separate 8K writes at buffer write-out time.

It's not quite that bad.  The double-write area is going to be a small 
chunk of re-used sequential I/O, like the current WAL.  And if this 
approach shifts some of the full-page writes out of the WAL and toward 
the new area instead, that's not a real doubling either.  Could probably 
put both on the same disk, and in situations where you don't have a 
battery-backed write cache it's possible to get a write to both per 
rotation.

This idea has been tested pretty extensively as part of MySQL's Innodb 
engine.  Results there suggest the overhead is in the 5% to 30% range; 
some examples mentioning both extremes of that:

http://www.mysqlperformanceblog.com/2006/08/04/innodb-double-write/
http://www.bigdbahead.com/?p=392

Makes me wish I knew off the top of my head how expensive WAL logging 
hint bits would be, for comparison sake.


-- 
Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

In response to

pgsql-hackers by date

Next:From: Peter GeogheganDate: 2012-01-10 06:48:11
Subject: Re: Progress on fast path sorting, btree index creation time
Previous:From: Tom LaneDate: 2012-01-10 05:00:20
Subject: Re: Sending notifications from the master to the standby

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group