> Yes. The visibility map doesn't need any new WAL records to be written. > > We probably will need to add some WAL logging to close the holes with > crash recovery, required for relying on it for index-only-scans, but > AFAICS only for VACUUM and probably only one WAL record for a whole > bunch of heap pages, so it should be pretty insignificant. >
Hmmm.... So whenever the update transaction changes a page, it will update the visibility map, but won't enter the WAL record. So after the crash we have a visibility map, which has false positives. Isn't that wrong? > > Let me repeat myself: if you think the overhead of a visibility map is > noticeable or meaningful in any scenario, the onus is on you to show > what that scenario is. I am not aware of such a scenario, which doesn't > mean that it doesn't exist, of course, but hand-waving is not helpful. > Well as a DB Tuner, i am requesting to make it a optional feature. If you and everyone else feel convinced, consider my request. > > > I'm not sure what you mean with "without any page level locking". > Whenever a visibility map page is read or modified, a lock is taken on > the buffer. > > OK. I thought you are following some kind of lock-less algorithm there. Then updaters/deleters of multiple pages might be waiting on the same lock and hence there is a chance of a contention there right? Again correct me, if i am wrong ( i might have understood things incorrectly ) Thanks, Gokul.
