On 7/5/25 09:09, Cédric Villemain wrote:
> Hi Tomas,
>
>
> I haven't yet had time to fully read all the work and proposals around
> NUMA and related features, but I hope to catch up over the summer.
>
> However, I think it's important to share some thoughts before it's too
> late, as you might find them relevant to the NUMA management code.
>
>
>> 6) v1-0006-NUMA-pin-backends-to-NUMA-nodes.patch
>>
>> This is an experimental patch, that simply pins the new process to the
>> NUMA node obtained from the freelist.
>>
>> Driven by GUC "numa_procs_pin" (default: off).
>
>
> In my work on more careful PostgreSQL resource management, I've come to
> the conclusion that we should avoid pushing policy too deeply into the
> PostgreSQL core itself. Therefore, I'm quite skeptical about integrating
> NUMA-specific management directly into core PostgreSQL in such a way.
>
>
> We are working on a PROFILE and PROFILE MANAGER specification to provide
> PostgreSQL with only the APIs and hooks needed so that extensions can
> manage whatever they want externally.
>
> The basic syntax (not meant to be discussed here, and even the names
> might change) is roughly as follows, just to illustrate the intent:
>
>
> CREATE PROFILE MANAGER manager_name [IF NOT EXISTS]
> [ HANDLER handler_function | NO HANDLER ]
> [ VALIDATOR validator_function | NO VALIDATOR ]
> [ OPTIONS ( option 'value' [, ... ] ) ]
>
> CREATE PROFILE profile_name
> [IF NOT EXISTS]
> USING profile_manager
> SET key = value [, key = value]...
> [USING profile_manager
> SET key = value [, key = value]...]
> [...];
>
> CREATE PROFILE MAPPING
> [IF NOT EXISTS]
> FOR PROFILE profile_name
> [MATCH [ ALL | ANY ] (
> [ROLE role_name],
> [BACKEND TYPE backend_type],
> [DATABASE database_name],
> [APPLICATION appname]
> )];
>
> ## PROFILE RESOLUTION ORDER
>
> 1. ALTER ROLE IN DATABASE
> 2. ALTER ROLE
> 3. ALTER DATABASE
> 4. First matching PROFILE MAPPING (global or specific)
> 5. No profile (fallback)
>
> As currently designed, this approach allows quite a lot of flexibility:
>
> * pg_psi is used to ensure the spec is suitable for a cgroup profile
> manager (moving PIDs as needed; NUMA and cgroups could work well
> together, see e.g. this Linux kernel summary: https://blogs.oracle.com/
> linux/post/numa-balancing )
>
> * Someone else could implement support for Windows or BSD specifics.
>
> * Others might use it to integrate PostgreSQL's own resources (e.g.,
> "areas" of shared buffers) into policies.
>
> Hope this perspective is helpful.
Can you explain how you want to manage this by an extension defined at
the SQL level, when most of this stuff has to be done when setting up
shared memory, which is waaaay before we have any access to catalogs?
regards
--
Tomas Vondra
