Re: WIP: bufmgr rewrite per recent discussions
От | Tom Lane |
---|---|
Тема | Re: WIP: bufmgr rewrite per recent discussions |
Дата | |
Msg-id | 7346.1108655184@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP: bufmgr rewrite per recent discussions ("Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk>) |
Ответы |
Re: WIP: bufmgr rewrite per recent discussions
|
Список | pgsql-patches |
"Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk> writes: > As I see it, there is not much noticeable performance gain (and maybe even a > small loss)with the padding included. Looks that way. Of course we should never trust a single test case very far, but this suggests that there's not a whole lot of gold to be mined by padding out the buffer headers. >> 3. Pad the LWLock struct (in >> src/backend/storage/lmgr/lwlock.c) to some power of 2 up to >> 128 bytes --- same issue of space wasted versus cross-lock contention. > Having seen the results above, is it still worth looking at this? Yeah, probably, because there are other possible contention sources besides buffers that might be alleviated by padding LWLocks. For instance the buffer manager global locks and the LockMgrLock are probably all in the same cache line at the moment. Thanks for running these tests. regards, tom lane
В списке pgsql-patches по дате отправления: