Re: Draft for basic NUMA observability
Tomas Vondra <tomas@vondra.me>
From: Tomas Vondra <tomas@vondra.me>
To: Jakub Wartak <jakub.wartak@enterprisedb.com>,
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
Nazir Bilal Yavuz <byavuz81@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-04-07T15:11:11Z
Lists: pgsql-hackers
Attachments
- v26-0001-Add-support-for-basic-NUMA-awareness.patch (text/x-patch) patch v26-0001
- v26-0002-review.patch (text/x-patch) patch v26-0002
- v26-0003-Introduce-pg_shmem_allocations_numa-view.patch (text/x-patch) patch v26-0003
- v26-0004-review.patch (text/x-patch) patch v26-0004
- v26-0005-Add-pg_buffercache_numa-view-with-NUMA-node-info.patch (text/x-patch) patch v26-0005
- v26-0006-reworks.patch (text/x-patch) patch v26-0006
- v26-0007-fixup.patch (text/x-patch) patch v26-0007
Hi, Here's a v26 of this patch series, merging the various fixup patches. I've also reordered the patches so that the pg_buffercache part is last. The two other patches are ready to go, and it seems better to push the built-in catalog before the pg_buffercache contrib module. For 0001 and 0002, I only have some minor tweaks - comment rewordings etc. I kept them in separate patches to make it obvious, but I think it's fine. The one specific tweak is to account for the +1 page, which might happen if the buffers/pages are shifted in some way. For 0003, I made some more serious changes - I reworked how buffers and pages are mapped. I concluded that relying on pages_per_buffer and buffer_per_pages is way too fiddly, if we can't guarantee the buffers are not "shifted" in some way. Which I think we can't. So I reworked that so that os_page_ptrs always points to actual pages without duplicate pointers. And then for each buffer we calculate the first page / last page, and iterate over those. A comment suggested the old code made the retrieval simpler, but I find the new approach much easier. And it doesn't have to worry how are the pages/buffers shifted and so on. The one caveat is that we can't know how many entries the function will produce until after going through the buffers. We can say only calculate the maximum number of entries. I think that's fine - we may allocate a bit more space than needed, but we also save space in os_page_status. I intend to push 0001 and 0002 shortly, and 0003 after a bit more review and testing, unless I hear objections. regards -- Tomas Vondra
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
doc: Correct pg_shmem_allocations_numa.size data type
- b8a6078ca8f4 18.0 landed
-
Add pg_buffercache_numa view with NUMA node info
- ba2a3c2302f1 18.0 landed
-
Add support for basic NUMA awareness
- 65c298f61fc7 18.0 landed
-
Introduce pg_shmem_allocations_numa view
- 8cc139bec34a 18.0 landed