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.
