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

  1. Increase upper bound for bgwriter_lru_maxpages.