Re: BufFreelistLock

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: BufFreelistLock
Дата
Msg-id AANLkTinnGtb-EsZbggLXFF_V=eYNhW14eOAcxZ9Sn2DR@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BufFreelistLock  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: BufFreelistLock  (Alvaro Herrera <alvherre@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: serializable read only deferrable
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: initdb failure with Postgres 8.4.4