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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Csaba Nagy
Дата:
Сообщение: Re: generalizing the planner knobs
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: generalizing the planner knobs