Re: [HACKERS] Time to up bgwriter_lru_maxpages?
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] Time to up bgwriter_lru_maxpages? |
Дата | |
Msg-id | a8e6ba38-92d0-b0b1-1072-bd26f700bf18@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Time to up bgwriter_lru_maxpages? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Time to up bgwriter_lru_maxpages?
|
Список | pgsql-hackers |
On 2/1/17 10:27 AM, Robert Haas wrote: > On Tue, Jan 31, 2017 at 5:07 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >> On 11/29/16 9:58 AM, Jeff Janes wrote: >>> 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? >> >> >> Attached is a patch that ups the limit to INT_MAX / 2, which is the same as >> shared_buffers. > > This looks fine to me. If someone wants to proactively commit this, the CF entry is https://commitfest.postgresql.org/13/979/. (BTW, the Jan. CF is still showing as in-progress...) -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)
В списке pgsql-hackers по дате отправления: