Gokulakannan Somasundaram wrote: > 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.
The WAL record of the heap insert/update/delete contains a flag indicating that the visibility map needs to be updated too. Thus no need for a separate WAL record. >> 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. There is no point in making something optional, if there is no scenarios where you would want to turn it off. >> 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? Yeah, there is some potential for contention. But again it doesn't seem to be a problem in any real-life scenario; I didn't see any in the test I performed, and IIRC I did try to invoke that case, and there has been no reports of contention from users. If it ever becomes a problem, maybe you could indeed switch to a lock-less algorithm, but there doesn't seem to be any need for that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
