Re: [HACKERS] Time to up bgwriter_lru_maxpages? - Mailing list pgsql-hackers

From David Steele
Subject Re: [HACKERS] Time to up bgwriter_lru_maxpages?
Date
Msg-id 7dbe0107-336b-e96f-e791-b37a4c6bd44c@pgmasters.net
Whole thread Raw
In response to Re: [HACKERS] Time to up bgwriter_lru_maxpages?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Time to up bgwriter_lru_maxpages?  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: David Steele
Date:
Subject: Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Time to up bgwriter_lru_maxpages?