Re: Time to up bgwriter_lru_maxpages?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Time to up bgwriter_lru_maxpages?
Date: 2017-02-02 19:47:53
Message-ID: CA+TgmoZr=wOhaC_tVivvBg6d86O=kwipfjpWM_agEJJXZpDkZQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 1, 2017 at 9:47 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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. :-)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-02-02 19:50:35 Re: Time to up bgwriter_lru_maxpages?
Previous Message Jim Nasby 2017-02-02 19:41:44 Re: Time to up bgwriter_lru_maxpages?