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