Re: Time to up bgwriter_lru_maxpages?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: "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: 2016-11-29 17:58:50
Message-ID: CAMkU=1x6E5=paCc=kSQ=Tu19dFwvpMYBELc4JN_Ywekev-infQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 28, 2016 at 1:20 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> On 11/28/16 11:53 AM, Joshua D. Drake wrote:
>
>> On 11/28/2016 11:40 AM, Jim Nasby wrote:
>>
>>> With current limits, the most bgwriter can do (with 8k pages) is 1000
>>> pages * 100 times/sec = 780MB/s. It's not hard to exceed that with
>>> modern hardware. Should we increase the limit on bgwriter_lru_maxpages?
>>>
>>
>> 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?

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-11-29 17:59:43 Re: Improving RLS planning
Previous Message Tom Lane 2016-11-29 17:58:42 Re: GiST support for UUIDs