> Hmm, you have a point. If 100 backends simultaneously write to 100 > different pages, and all of those pages are all-visible, then it's > possible that they could end up fighting over the buffer content lock > on the visibility map page. But why would you expect that to matter? > In a heavily updated table, the proportion of visibility map bits that > are set figures to be quite low, since they're only set during VACUUM. > To have 100 backends simultaneously pick different pages to write > each of which is all-visible seems really unlucky. Even if it does > happen from time to time, I suspect the effects would be largely > masked by WALInsertLock contention. The visibility map content lock > is only taken very briefly, whereas the operations protected by > WALInsertLock are much more complex. >
by your argument, if WALInserLock is held for 't' seconds, you should definitely be holding visibility map lock for more than time frame 't' . So the index scans have to wait for acquiring the lock on visibility map to check visibility. What we are trading off here is Synchronization Vs I/O. Should we lose the scalability for performance?? Gokul.
