Re: the big picture for index-only scans
| От | Gokulakannan Somasundaram |
|---|---|
| Тема | Re: the big picture for index-only scans |
| Дата | |
| Msg-id | CAHMh4-YXnSSOxv+KosKyLn9Nq8SwPfskCGYD9W68Ffgoe2u+Yg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: the big picture for index-only scans (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: the big picture for index-only scans
|
| Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: