Re: the big picture for index-only scans

> 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.