Re: collateral benefits of a crash-safe visibility map

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: collateral benefits of a crash-safe visibility map
Date: 2011-05-10 17:38:31
Message-ID: BANLkTim1TM6+oo_zMe0XTUFYE80Trf0fjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 10, 2011 at 9:47 AM, Robert Haas <robertmhaas(at)gmail(dot)com> 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.)

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ross J. Reedstrom 2011-05-10 17:42:34 Re: Collation mega-cleanups
Previous Message Greg Smith 2011-05-10 17:33:50 Re: Formatting Curmudgeons WAS: MMAP Buffers