Re: Removing PD_ALL_VISIBLE

At 2013-01-17 08:41:37 +0000, simon@2ndQuadrant.com wrote:
>
> Jeff, can you summarise/collate why we're doing this, what concerns it
> raises and how you've dealt with them?

Since I was just looking at the original patch and discussion, and since
Pavan has posted an excerpt from one objection to it, here's an excerpt
from Jeff's original post titled "Do we need so many hint bits?"

http://www.postgresql.org/message-id/1353026577.14335.91.camel@sussancws0025
   Also, I am wondering about PD_ALL_VISIBLE. It was originally   introduced in the visibility map patch, apparently as
away to know   when to clear the VM bit when doing an update. It was then also used   for scans, which showed a
significantspeedup. But I wonder: why not   just use the visibilitymap directly from those places? It can be   used for
thescan because it is crash safe now (not possible   before). And since it's only one lookup per scanned page, then I
don'tthink it would be a measurable performance loss there.   Inserts/updates/deletes also do a significant amount of
work,so   again, I doubt it's a big drop in performance there -- maybe under a   lot of concurrency or something.
 
   The benefit of removing PD_ALL_VISIBLE would be significantly   higher. It's quite common to load a lot of data, and
thendo some   reads for a while (setting hint bits and flushing them to disk), and   then do a VACUUM a while later,
settingPD_ALL_VISIBLE and writing   all of the pages again. Also, if I remember correctly, Robert went   to significant
effortwhen making the VM crash-safe to keep the   PD_ALL_VISIBLE and VM bits consistent. Maybe this was all discussed
before?

There was considerable discussion after this (accessible through the
archives link above), which I won't attempt to summarise.

-- Abhijit