Re: Draft for basic NUMA observability
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Tomas Vondra <tomas@vondra.me>
Cc: Jakub Wartak <jakub.wartak@enterprisedb.com>, 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-05T09:37:51Z
Lists: pgsql-hackers
Attachments
- nit-bertrand-0002.txt (text/plain)
Hi, On Fri, Apr 04, 2025 at 09:25:57PM +0200, Tomas Vondra wrote: > OK, > > here's v25 after going through the patches once more, fixing the issues > mentioned by Bertrand, etc. Thanks! > I think 0001 and 0002 are fine, Agree, I just have some cosmetic nits comments: please find them in nit-bertrand-0002.txt attached. > I have a > couple minor questions about 0003. > > - I was wondering if maybe we should have some "global ID" of memory > page, so that with large memory pages it's indicated the buffers are on > the same memory page. Right now each buffer starts page_num from 0, but > it should not be very hard to have a global counter. Opinions? I think that's a good idea. We could then add a new column (say os_page_id) that would help identify which buffers are sharing the same "physical" page. > 0003 > ---- > - Minor formatting tweaks, comment improvements. > - Isn't this comment a bit confusing / misleading? > > /* Get number of OS aligned pages */ > > AFAICS the point is to adjust the allocated_size to be a multiple of > os-page_size, to get "all" memory pages the segment uses. But that's not > what I understand by "aligned page" (which is about there the page is > expected to start). Agree, what about? " Align the start of the allocated size to an OS page size boundary and then get the total number of OS pages used by this segment" " > - There's a comment at the end which talks about "ignored segments". > IMHO that type of information should be in the function comment, > but I'm > also not quite sure I understand what "output shared memory" is ... I think that comes from the comments that are already in pg_get_shmem_allocations(). I think that those are located here and worded that way to ease to understand what is not in with pg_get_shmem_allocations_numa() if one look at both functions. That said, I'm +1 to put this kind of comments in the function comment. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
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