Re: Estimating HugePages Requirements? - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Estimating HugePages Requirements?
Date
Msg-id 0D1645F3-ADFD-4B2F-9F34-961BDFBB881B@amazon.com
Whole thread Raw
In response to Re: Estimating HugePages Requirements?  (Andres Freund <andres@anarazel.de>)
Responses Re: Estimating HugePages Requirements?  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
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 generic
> way. While this is the most problematic runtime computed GUC, it's not the
> only one. What if we introduced a new shared_memory_size GUC, and made
> --describe-config output it? Perhaps adding --describe-config=guc-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 rounding up
> could be removed in that case. Due to huge_page_size it's not even immediately
> obvious which huge page size one should use...

I like both of these ideas.

> Can you split this into a separate commit? It feels fairy uncontroversial to
> me, so I think we could just apply it soon?

I attached a patch for just the uncontroversial part, which is
unfortunately all I have time for today.

Nathan


Attachment

pgsql-hackers by date:

Previous
From: "Andres Freund"
Date:
Subject: Re: Queries that should be canceled will get stuck on secure_write function
Next
From: Peter Geoghegan
Date:
Subject: Re: log_autovacuum in Postgres 14 -- ordering issue