From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Jim Nasby <jim(at)nasby(dot)net>, 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-10 15:24:34 |
Message-ID: | AANLkTinnGtb-EsZbggLXFF_V=eYNhW14eOAcxZ9Sn2DR@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 10, 2010 at 5:45 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)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 what the 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 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.
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-12-10 15:25:33 | Re: initdb failure with Postgres 8.4.4 |
Previous Message | Kevin Grittner | 2010-12-10 15:22:09 | Re: serializable read only deferrable |