Re: Time to up bgwriter_lru_maxpages?

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Time to up bgwriter_lru_maxpages?
Date: 2017-02-01 22:01:43
Message-ID: a8e6ba38-92d0-b0b1-1072-bd26f700bf18@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(dot)Nasby(at)bluetreble(dot)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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2017-02-01 22:07:50 Re: Cast jsonb to numeric, int, float, bool
Previous Message Michael Paquier 2017-02-01 22:01:22 Re: Refactoring of replication commands using printsimple