Re: bgwriter_lru_multiplier blurbs inconsistent

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: bgwriter_lru_multiplier blurbs inconsistent
Дата
Msg-id Pine.GSO.4.64.0801201505250.17332@westnet.com
обсуждение исходный текст
Ответ на bgwriter_lru_multiplier blurbs inconsistent  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: bgwriter_lru_multiplier blurbs inconsistent  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, 20 Jan 2008, Alvaro Herrera wrote:

> Is the bgwriter_lru_multiplier parameter a limit on the number to scan
> or to write?  GUC and docs seem to contradict one another.

It adjusts the target for how many clean buffers it wants to either find
or create.  This always increases the number of buffers scanned, and
that's what the GUC description says.

Since a clean buffer can either be a) a reusable candidate found by
scanning or b) a buffer that is written, on average it's adjusting up the
number of writes as well.  But it's not guaranteed to--you could have a
case where it just found all the buffers it needed and never wrote a
single one.

>         Unless limited by <varname>bgwriter_lru_maxpages</>, the number
>         of dirty buffers written in each round is determined by reference
>         to the number of new buffers that have been needed by server
>         processes during recent rounds.  This number is multiplied by
>         <varname>bgwriter_lru_multiplier</> to arrive at the estimate
>         of the number of buffers that will be needed during the next round.

There is nothing incorrect here, it's just not as clear as it could be.
Here's a V2 that tries to clear that up:

Unless limited by <varname>bgwriter_lru_maxpages</>, the number of dirty
buffers written in each round is based on the number of new buffers that
have been needed by server processes during recent rounds.  The recent
need is multiplied by <varname>bgwriter_lru_multiplier</> to arrive at the
estimate of the number of buffers that will be needed during the next
round.  Buffers are written to meet that need if there aren't enough
reusable ones found while scanning.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: [GENERAL] SHA1 on postgres 8.3
Следующее
От: Mark Cave-Ayland
Дата:
Сообщение: Minor bug in src/port/rint.c