Re: collateral benefits of a crash-safe visibility map

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: collateral benefits of a crash-safe visibility map
Date: 2011-05-10 17:22:20
Message-ID: 4DC9744C.9020601@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10.05.2011 17:47, Robert Haas wrote:
> On Tue, May 10, 2011 at 9:59 AM, Merlin Moncure<mmoncure(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-05-10 17:25:34 Re: the big picture for index-only scans
Previous Message Andres Freund 2011-05-10 17:21:16 Re: Collation mega-cleanups