Re: BufFreelistLock - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: BufFreelistLock
Date
Msg-id AANLkTinnGtb-EsZbggLXFF_V=eYNhW14eOAcxZ9Sn2DR@mail.gmail.com
Whole thread Raw
In response to Re: BufFreelistLock  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: BufFreelistLock  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Fri, Dec 10, 2010 at 5:45 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Jim Nasby's message of jue dic 09 16:54:24 -0300 2010:
>
>> Ideally, the clock sweep would be run by bgwriter and not individual backends. In that case it shouldn't matter much
whatthe performance of the sweep is. 

Lock contention between the bgwriter and the individual backends would
matter very much.  This might actually make things worse.  Now you
need two BufFreelistLocks, one to stick it on the freelist, and one to
take it off.

>> 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
inaddition to) targeting how many dirty buffers need to be written. This would mirror what operating systems do; they
striveto keep X number of pages on the free list so that when a process needs memory it can get it quickly. 
>
> Isn't it what it does if you set bgwriter_lru_maxpages to some very
> large value?

As far as I can tell, bgwriter never adds things to the freelist.
That is only done at start up, and when a relation or a database is
dropped.  The clock sweep does the vast majority of the work.

But I could be wrong.

Cheers,

Jeff


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: serializable read only deferrable
Next
From: Andrew Dunstan
Date:
Subject: Re: initdb failure with Postgres 8.4.4