From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BufFreelistLock |
Date: | 2010-12-09 19:54:24 |
Message-ID: | 0449DD6E-83E9-445B-8850-8F3402C1CF56@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Dec 8, 2010, at 11:44 PM, Jeff Janes wrote:
>>> For the clock sweep algorithm, I think you could access
>>> nextVictimBuffer without any type of locking.
>>
>> This is wrong, mainly because you wouldn't have any security against two
>> processes decrementing the usage count of the same buffer because they'd
>> fetched the same value of nextVictimBuffer. That would probably happen
>> often enough to severely compromise the accuracy of the usage counts and
>> thus the accuracy of the LRU eviction behavior. See above.
>
> Ah, I hadn't considered that.
Ideally, the clock sweep would be run by bgwriter and not individual backends. In that case it shouldn't matter much what the performance of the sweep is. To do that I think we'd want the bgwriter to target there being X number of buffers on the free list instead of (or in addition to) targeting how many dirty buffers need to be written. This would mirror what operating systems do; they strive to keep X number of pages on the free list so that when a process needs memory it can get it quickly.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-12-09 19:56:15 | Re: initdb failure with Postgres 8.4.4 |
Previous Message | Kevin Grittner | 2010-12-09 19:51:58 | Re: Patch to add a primary key using an existing index |