Date: Sat, 28 Aug 2021 11:00:11 +0900
From: Michael Paquier <michael@paquier.xyz>
To: "Bossart, Nathan" <bossartn@amazon.com>
Cc: Andres Freund <andres@anarazel.de>,
	Magnus Hagander <magnus@hagander.net>,
	Mark Dilger <mark.dilger@enterprisedb.com>,
	Don Seiler <don@seiler.us>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Estimating HugePages Requirements?
Message-ID: <YSmYq5Z4GAf8NzxM@paquier.xyz>
References: <73A4E25F-1039-4FC9-8E6E-0A00230BDFB8@enterprisedb.com>
 <92BB93C3-1AA8-4548-96F7-062C4AF09182@amazon.com>
 <20210810034205.r72j5uouynepj4f2@alap3.anarazel.de>
 <0545F7B3-70C0-4DE8-8C85-EAFE6113B7EE@amazon.com>
 <YSiKS58gSXDpj6NR@paquier.xyz>
 <CABUevEwGHcsmp4rgZdcbinZOdEs_cSCabihDvRty=0zz1H95kw@mail.gmail.com>
 <20210827184648.d3jbv73pgyccqwkz@alap3.anarazel.de>
 <071DC95B-4CA8-4D2B-BD24-1A66B3EFFE28@amazon.com>
 <20210827193813.oqo5lamvyzahs35o@alap3.anarazel.de>
 <0D1645F3-ADFD-4B2F-9F34-961BDFBB881B@amazon.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="+3g2ABFDKnnRiK3d"
Content-Disposition: inline
In-Reply-To: <0D1645F3-ADFD-4B2F-9F34-961BDFBB881B@amazon.com>
Archived-At: 
 <https://www.postgresql.org/message-id/YSmYq5Z4GAf8NzxM%40paquier.xyz>
Precedence: bulk


--+3g2ABFDKnnRiK3d
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 27, 2021 at 08:16:40PM +0000, Bossart, Nathan wrote:
> On 8/27/21, 12:39 PM, "Andres Freund" <andres@anarazel.de> wrote:
>> One thing I wonder is if this wouldn't better be dealt with in a more ge=
neric
>> way. While this is the most problematic runtime computed GUC, it's not t=
he
>> only one. What if we introduced a new shared_memory_size GUC, and made
>> --describe-config output it? Perhaps adding --describe-config=3Dguc-name?
>>
>> I also wonder if we should output the number of hugepages needed instead=
 of
>> the "raw" bytes of shared memory. The whole business about figuring out =
the
>> huge page size, dividing the shared memory size by that and then roundin=
g up
>> could be removed in that case. Due to huge_page_size it's not even immed=
iately
>> obvious which huge page size one should use...
>=20
> I like both of these ideas.

That pretty much looks like -C in concept, isn't it?  Except that you
cannot get the actual total shared memory value because we'd do this
operation before loading shared_preload_libraries and miss any amount
asked by extensions.  There is a problem similar when attempting to do
postgres -C data_checksums, for example, which would output an
incorrect value even if the cluster has data checksums enabled.
--
Michael

--+3g2ABFDKnnRiK3d
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmEpmKsACgkQnvQgOdby
QH3ITQ/+PaQGNmp8gNmf+0Hor11EzdAfPhxe3fM6M1r2HaoK1925bJWK8wvquA9d
FCiS5PTRjcrLS0BCyOiIAce4ip40SZbbBXYiwduMVR+xIYPXHLUuDNt9lZe3ZV/W
wJBTwFyrmg08GKLJW76eXETwp7obIsYvchmrqUbqnMrzMASWRnUwum6oiF0eDi99
toVPlrqyQKmad9Q8yP5PC8JRuMHpri+7mFiADFYFW4ikBU+ScmGjtZnnEX985BHK
FRIlApxiWAoTD4zuod5wfiSTDYOO9WTSQEgcnLWLgfI0nJZnY2GVAELdQZ2MH7HU
bmbZ3NEbuX7+HB62h3gcwXZlqMAxk96YJxVx5NQSinB6dqN4C5NMNdHLFuKMLkst
vokSPK56yRedJp1sfP8oGitn8ds70CiSfmF9A3ytJr041PzzHnE4FyfzvJwGKftz
jxpqLmBWwiN5p2tVbLdzZBF0haXapcU52dpehF2C69XNfr+jQnyY7uQ8AJeqFWqo
PGkCSj5XcAbiv0bfxZQVhV9bBeLaPYzctOScmt5lHUdw9BeBQZZRCekXiSVBrpSU
7LQd7xwPyCwFvelhj4hjPr0K4IqH2Tq+IrLOXbLrQ1phFyTuo9yXJBpNlk6pTCOR
QH8IEf0E9O6V7UUD+52RpGUUcRiw5zn2Pw662pcvOhhSmxg1uIk=
=MRQr
-----END PGP SIGNATURE-----

--+3g2ABFDKnnRiK3d--