On 2/1/17 10:27 AM, Robert Haas wrote:
On Tue, Jan 31, 2017 at 5:07 PM, Jim Nasby <jim.na...@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)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
