Re: Adding basic NUMA awareness
Jakub Wartak <jakub.wartak@enterprisedb.com>
From: Jakub Wartak <jakub.wartak@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tomas@vondra.me>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-07-10T10:16:41Z
Lists: pgsql-hackers
On Wed, Jul 9, 2025 at 9:42 PM Andres Freund <andres@anarazel.de> wrote: > On 2025-07-01 21:07:00 +0200, Tomas Vondra wrote: > > Each patch has a numa_ GUC, intended to enable/disable that part. This > > is meant to make development easier, not as a final interface. I'm not > > sure how exactly that should look. It's possible some combinations of > > GUCs won't work, etc. > > Wonder if some of it might be worth putting into a multi-valued GUC (like > debug_io_direct). Long-term or for experimentation? Also please see below as it is related: [..] > FWIW, I don't think that's a safe assumption anymore. With CXL we can get a) > PCIe attached memory and b) remote memory as a separate NUMA nodes, and that > very well could end up as more NUMA nodes than cores. In my earlier apparently very way too naive approach, I've tried to handle this CXL scenario, but I'm afraid this cannot be done without further configuration, please see review/use cases [1] and [2] -J. [1] https://www.postgresql.org/message-id/attachment/178119/v4-0001-Add-capability-to-interleave-shared-memory-across.patch - just see sgml/GUC and we have numa_parse_nodestring(3) [2] https://www.postgresql.org/message-id/aAKPMrX1Uq6quKJy%40ip-10-97-1-34.eu-west-3.compute.internal
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Sort guc_parameters.dat alphabetically by name
- fce7c73fba4e 19 (unreleased) cited