Re: Time to up bgwriter_lru_maxpages?
Jim Nasby <jim.nasby@bluetreble.com>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, "Joshua D. Drake" <jd@commandprompt.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-02-01T22:01:43Z
Lists: 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)
Commits
-
Increase upper bound for bgwriter_lru_maxpages.
- 14ca9abfbe46 10.0 landed