Re: collateral benefits of a crash-safe visibility map - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: collateral benefits of a crash-safe visibility map
Date
Msg-id 4DC9744C.9020601@enterprisedb.com
Whole thread Raw
In response to collateral benefits of a crash-safe visibility map  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 10.05.2011 17:47, Robert Haas wrote:
> On Tue, May 10, 2011 at 9:59 AM, Merlin Moncure<mmoncure@gmail.com>  wrote:
>> no, that wasn't my intent at all, except in the sense of wondering if
>> a crash-safe visibility map provides a route of displacing a lot of
>> hint bit i/o and by extension, making alternative approaches of doing
>> that, including mine, a lot less useful.  that's a good thing.
>
> Sadly, I don't think it's going to have that effect.  The
> page-is-all-visible bits seem to offer a significant performance
> benefit over the xmin-committed hint bits; but the benefit of
> xmin-committed all by itself is too much to ignore.  The advantages of
> the xmin-committed hint bit (as opposed to the all-visible page-level
> bit) are:
>
> (1) Setting the xmin-committed hint bit is a much more light-weight
> operation than setting the all-visible page-level bit.  It can by done
> on-the-fly by any backend, rather than only by VACUUM, and need not be
> XLOG'd.
> (2) If there are long-running transactions on the system,
> xmin-committed can be set much sooner than all-visible - the
> transaction need only commit.  All-visible can't be set until
> overlapping transactions have ended.
> (3) xmin-committed is useful on standby servers, whereas all-visible
> is ignored there.  (Note that neither this patch nor index-only scans
> changes anything about that: it's existing behavior, necessitated by
> different xmin horizons.)

(4) xmin-committed flag attached directly to the tuple provides some 
robustness in case of corruption, due to bad hw. Without the flag, a 
single bit flip in the clog could in the worst case render all of your 
bulk-loaded data invisible and vacuumable. Of course, corruption will 
always eat your data to some extent, but the hint bits provide some 
robustness. Hint bits are close to the data itself, not in another file 
like the clog, which can come handy at disaster recovery.

A flag in the heap page header isn't too different from a per-tuple hint 
bit from that point of view, it's still in the same page as the data 
itself. A bit in the clog or visibility map is not.

Not sure how much performance we're willing to sacrifice for that, but 
it's something to keep in mind.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Collation mega-cleanups
Next
From: "Kevin Grittner"
Date:
Subject: Re: the big picture for index-only scans