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
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
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
Author: Jim Nasby <jim.na...@bluetreble.com>
Date: Tue Jan 31 15:55:15 2017 -0600
Increase upper limit for bgwriter_lru_maxpages
The old maximum limited the bgwriter to 780MB/s with 8k pages and a
bgwriter_delay of 10ms. Modern hardware can easily exceed that.
Current code does not depend on any limits to this setting (at most it
will make one complete pass through shared buffers per round), but
setting it higher than the maximum for shared_buffers is surely an
error, so treat it as such.
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 74ca4e7432..e9642fe609 100644
@@ -1843,7 +1843,7 @@ static struct config_int ConfigureNamesInt =
- 1024, 16, INT_MAX / 2,
+ 1024, 16, INT_MAX / 2, /* See also bgwriter_lru_maxpages. */
NULL, NULL, NULL
@@ -2419,7 +2419,7 @@ static struct config_int ConfigureNamesInt =
- 100, 0, 1000,
+ 100, 0, INT_MAX / 2, /* Same upper limit as shared_buffers */
NULL, NULL, NULL
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: