Re: collateral benefits of a crash-safe visibility map
От | Merlin Moncure |
---|---|
Тема | Re: collateral benefits of a crash-safe visibility map |
Дата | |
Msg-id | BANLkTim1TM6+oo_zMe0XTUFYE80Trf0fjQ@mail.gmail.com обсуждение исходный текст |
Ответ на | collateral benefits of a crash-safe visibility map (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: