Re: Shared locking in slru.c
От | Manfred Koizar |
---|---|
Тема | Re: Shared locking in slru.c |
Дата | |
Msg-id | t870p1d9ooqa3j6juglrv4vvq68gh7ncue@4ax.com обсуждение исходный текст |
Ответ на | Shared locking in slru.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Shared locking in slru.c
|
Список | pgsql-hackers |
On Wed, 30 Nov 2005 13:53:13 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote: >The way the attached patch attacks this is for the shared-lock access >case to simply set the page's LRU counter to zero, without bumping up >the LRU counters of the other pages as the normal adjustment would do. If you still plan to do this, you might also want to revert the micro-optimisation intruduced by the original SLRU patch: | Apart from refactoring I made a little change to SlruRecentlyUsed, | formerly ClogRecentlyUsed: It now skips incrementing lru_counts, if | slotno is already the LRU slot, thus saving a few CPU cycles. |+#define SlruRecentlyUsed(shared, slotno) \ |+ do { \ |+ if ((shared)->page_lru_count[slotno] != 0) { \ |+ int iilru; \ |+ for (iilru = 0; iilru < NUM_CLOG_BUFFERS; iilru++) \ |+ (shared)->page_lru_count[iilru]++; \ |+ (shared)->page_lru_count[slotno] = 0; \ |+ } \ |+ } while (0) Otherwise you could end up with a stable state of several pages having lru_count == 0. ServusManfred
В списке pgsql-hackers по дате отправления: