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

From Merlin Moncure
Subject Re: collateral benefits of a crash-safe visibility map
Date
Msg-id BANLkTim1TM6+oo_zMe0XTUFYE80Trf0fjQ@mail.gmail.com
Whole thread Raw
In response to collateral benefits of a crash-safe visibility map  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, May 10, 2011 at 9:47 AM, Robert Haas <robertmhaas@gmail.com> 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.)

right. #1 could maybe worked around somehow and #2 is perhaps
arguable, at least in some workloads, but #3 is admittedly a killer
especially since the bit is on the page.

I noted your earlier skepticism regarding moving the page visibility
check completely to the VM:
"In some ways, that would make things much simpler.  But to make that
work, every insert/update/delete to a page would have to pin the
visibility map page and clear PD_ALL_VISIBLE if appropriate, so it
might not be good from a performance standpoint, especially in
high-concurrency workloads.  Right now, if PD_ALL_VISIBLE isn't set,
we don't bother touching the visibility map page, which seems like a
possibly important optimization."

That's debatable, but probably moot.  Thanks for thinking that through though.

merlin


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Formatting Curmudgeons WAS: MMAP Buffers
Next
From: "J. Greg Davidson"
Date:
Subject: Re: 4.1beta1: ANYARRAY disallowed for DOMAIN types which happen to be arrays