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)
