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.
--
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)
commit 37e42579c5bdf8868109b157827bcac5ed83af7e
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
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -1843,7 +1843,7 @@ static struct config_int ConfigureNamesInt[] =
GUC_UNIT_BLOCKS
},
&NBuffers,
- 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[] =
NULL
},
&bgwriter_lru_maxpages,
- 100, 0, 1000,
+ 100, 0, INT_MAX / 2, /* Same upper limit as shared_buffers */
NULL, NULL, NULL
},
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
