Re: Time to up bgwriter_lru_maxpages? - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Time to up bgwriter_lru_maxpages?
Date
Msg-id CAMkU=1x6E5=paCc=kSQ=Tu19dFwvpMYBELc4JN_Ywekev-infQ@mail.gmail.com
Whole thread Raw
In response to Re: Time to up bgwriter_lru_maxpages?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: [HACKERS] Time to up bgwriter_lru_maxpages?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On Mon, Nov 28, 2016 at 1:20 PM, Jim Nasby <Jim.Nasby@bluetreble.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

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Proposal: scan key push down to heap [WIP]
Next
From: Tom Lane
Date:
Subject: Re: GiST support for UUIDs