Re: Time to up bgwriter_lru_maxpages?

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Time to up bgwriter_lru_maxpages?
Дата
Msg-id CAMkU=1x6E5=paCc=kSQ=Tu19dFwvpMYBELc4JN_Ywekev-infQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Time to up bgwriter_lru_maxpages?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: [HACKERS] Time to up bgwriter_lru_maxpages?
Список pgsql-hackers
On Mon, Nov 28, 2016 at 1:20 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
On 11/28/16 11:53 AM, Joshua D. Drake wrote:
On 11/28/2016 11:40 AM, Jim Nasby wrote:
With current limits, the most bgwriter can do (with 8k pages) is 1000
pages * 100 times/sec = 780MB/s. It's not hard to exceed that with
modern hardware. Should we increase the limit on bgwriter_lru_maxpages?

Considering a single SSD can do 70% of that limit, I would say yes.

Next question becomes... should there even be an upper limit?

Where the contortions needed to prevent calculation overflow become annoying?

I'm not a big fan of nannyism in general, but the limits on this parameter seem particularly pointless.  You can't write out more buffers than exist in the dirty state, nor more than implied by bgwriter_lru_multiplier.  So what is really the worse that can happen if you make it too high?


Cheers,

Jeff

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Proposal: scan key push down to heap [WIP]
Следующее
От: Tom Lane
Дата:
Сообщение: Re: GiST support for UUIDs