Re: [HACKERS] Time to up bgwriter_lru_maxpages?
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Time to up bgwriter_lru_maxpages? |
Дата | |
Msg-id | CA+TgmoZn-X-H-sQ6SeyAMAhr0+AHNJGQHPX9vZWXjBg3YHysfw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Time to up bgwriter_lru_maxpages? (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: [HACKERS] Time to up bgwriter_lru_maxpages?
|
Список | pgsql-hackers |
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: