Re: BufFreelistLock

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

In response to

Responses

Browse pgsql-hackers by date

  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