Re: [HACKERS] Time to up bgwriter_lru_maxpages?
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] Time to up bgwriter_lru_maxpages? |
Дата | |
Msg-id | 3f25f0e6-f9df-d30a-e53e-9ccaeba35300@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Time to up bgwriter_lru_maxpages? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Time to up bgwriter_lru_maxpages?
|
Список | pgsql-hackers |
On 2/1/17 4:27 PM, Andres Freund wrote: > On 2017-02-02 09:22:46 +0900, Michael Paquier wrote: >> On Thu, Feb 2, 2017 at 9:17 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >>> Speaking of which... I have a meeting in 15 minutes to discuss moving to a >>> server with 4TB of memory. With current limits shared buffers maxes at 16TB, >>> which isn't all that far in the future. While 16TB of shared buffers might >>> not be a good idea, it's not going to be terribly long before we start >>> getting questions about it. >> >> Time for int64 GUCs? > > I don't think the GUC bit is the hard part. We'd possibly need some > trickery (like not storing bufferid in BufferDesc anymore) to avoid > increasing memory usage. Before doing that the first thing to look at would be why the limit is currently INT_MAX / 2 instead of INT_MAX. -- 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)
В списке pgsql-hackers по дате отправления: