From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Shared locking in slru.c |
Date: | 2005-12-02 10:09:41 |
Message-ID: | t870p1d9ooqa3j6juglrv4vvq68gh7ncue@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 30 Nov 2005 13:53:13 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Anuj Tripathi | 2005-12-02 10:45:55 | Graphics in postgress using GTK |
Previous Message | Csaba Nagy | 2005-12-02 10:07:06 | Re: generalizing the planner knobs |