Re: [HACKERS] Time to up bgwriter_lru_maxpages?
От | David Steele |
---|---|
Тема | Re: [HACKERS] Time to up bgwriter_lru_maxpages? |
Дата | |
Msg-id | 7dbe0107-336b-e96f-e791-b37a4c6bd44c@pgmasters.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Time to up bgwriter_lru_maxpages? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Time to up bgwriter_lru_maxpages?
|
Список | pgsql-hackers |
On 2/2/17 2:47 PM, Robert Haas wrote: > On Wed, Feb 1, 2017 at 9:47 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >> Before doing that the first thing to look at would be why the limit is >> currently INT_MAX / 2 instead of INT_MAX. > > Generally the rationale for GUCs with limits of that sort is that > there is or might be code someplace that multiplies the value by 2 and > expects the result not to overflow. > > I expect that increasing the maximum value of shared_buffers beyond > what can be stored by an integer could have a noticeable distributed > performance cost for the entire system. It might be a pretty small > cost, but then again maybe not; for example, BufferDesc's buf_id > member would have to get wider, and probably the freeNext member, too. > Andres already did unspeakable things to make a BufferDesc fit into > one cache line for performance reasons, so that wouldn't be great > news. > > Anyway, I committed the patch posted here. Or the important line out > of the two, anyway. :-) It seems that this submission should be marked as "Committed" with Robert as the committer. Am I missing something? -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: