From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, simon(at)2ndquadrant(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, alvherre(at)commandprompt(dot)com, david(at)fetter(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Page Checksums + Double Writes |
Date: | 2011-12-27 22:43:23 |
Message-ID: | CAHyXU0xmcwBNGHdDW1NOnE7nUEAEfgKCcnmvDgsmr8N34Btdig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 27, 2011 at 1:24 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> 3. Attack hint bits problem.
A large number of problems would go away if the current hint bit
system could be replaced with something that did not require writing
to the tuple itself. FWIW, moving the bits around seems like a
non-starter -- you're trading a problem with a much bigger problem
(locking, wal logging, etc). But perhaps a clog caching strategy
would be a win. You get a full nibble back in the tuple header,
significant i/o reduction for some workloads, crc becomes relatively
trivial, etc etc.
My first attempt at a process local cache for hint bits wasn't perfect
but proved (at least to me) that you can sneak a tight cache in there
without significantly impacting the general case. Maybe the angle of
attack was wrong anyways -- I bet if you kept a judicious number of
clog pages in each local process with some smart invalidation you
could cover enough cases that scribbling the bits down would become
unnecessary. Proving that is a tall order of course, but IMO merits
another attempt.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-12-27 23:39:48 | Re: 16-bit page checksums for 9.2 |
Previous Message | Peter Eisentraut | 2011-12-27 20:16:13 | Re: Misleading CREATE TABLE error |