Re: Adding basic NUMA awareness - Preliminary feedback and outline for an extensible approach

From: Andres Freund <andres(at)anarazel(dot)de>
To: Cédric Villemain <cedric(dot)villemain(at)data-bene(dot)io>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Adding basic NUMA awareness - Preliminary feedback and outline for an extensible approach
Date: 2025-07-09 17:57:36
Message-ID: 7jo6wbucr3hnotrqsiw6k3ksdugerqn72qsc2ndne77v7pkwuz@22rnxu6grbc4
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2025-07-08 16:06:00 +0000, Cédric Villemain wrote:
> > Assuming we want to actually pin tasks from within Postgres, what I
> > think might work is allowing modules to "advise" on where to place the
> > task. But the decision would still be done by core.
>
> Possibly exactly what you're doing in proc.c when managing allocation of
> process, but not hardcoded in postgresql (patches 02, 05 and 06 are good
> candidates), I didn't get that they require information not available to any
> process executing code from a module.

> Parts of your code where you assign/define policy could be in one or more
> relevant routines of a "numa profile manager", like in an
> initProcessRoutine(), and registered in pmroutine struct:
>
> pmroutine = GetPmRoutineForInitProcess();
> if (pmroutine != NULL &&
> pmroutine->init_process != NULL)
> pmroutine->init_process(MyProc);
>
> This way it's easier to manage alternative policies, and also to be able to
> adjust when hardware and linux kernel changes.

I am doubtful this makes sense - as you can see patch 05 needs to change a
fair bit of core code to make this work, there's no way we can delegate much
of that to an extension.

But even if it's doable, I think it's *very* premature to focus on such
extensibility at this point - we need to get the basics into a mergeable
state, if you then want to argue for adding extensibility, we can do that at
this stage. Trying to design this for extensibility from the get go, where
that extensibility is very unlikely to be used widely, seems rather likely to
just tank this entire project without getting us anything in return.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2025-07-09 17:59:47 Re: [PoC] Federated Authn/z with OAUTHBEARER
Previous Message Nathan Bossart 2025-07-09 17:53:48 Re: Horribly slow pg_upgrade performance with many Large Objects