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
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 |