On Tue, Mar 18, 2025 at 3:29 PM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote:
Hi! v15 attached, rebased, CI-tested, all fixed incorporated. > > I've adjusted it all and settled on "numa_node_id" column name. > [...] > I think that we can get rid of the "numa_" stuff in column(s) name as > the column(s) are part of "numa" relation views/output anyway. [...] Done, you are probably right (it was done to keep consistency between those two views probably), I'm just not that strongly attached to the naming things. > > Please do such a check, > > Found much more: > [.. 9 issues with missing dots at the end of sentences in comments + fixes to comment structure in relation to HEAD..] All fixed. > > BTW if patch has anything left that > > causes pgident to fix, that is not picked by CI but it is picked by > > buildfarm?? > > I think it has to be done manually before each commit and that this is anyway > done at least once per release cycle. OK, thanks for clarification. [..] > > > > But 0002 used: > > > > "In order to get reliable results we also need to touch memory pages, so > > that > > inquiry about NUMA zone doesn't return -2 (which indicates > > unmapped/unallocated > > pages)" > > > > or are you looking at something different? > > Nope, I meant to say that it could make sense to have the exact same comment. Synced those two. [..] > > 0001 looks in a good shape from my point of view. Cool! > For 0002: > > === 1 > > I wonder if pg_buffercache_init_entries() and pg_buffercache_build_tuple() > could > deserve their own patch. That would ease the review for the "real" numa stuff. > Done, 0001+0002 alone passes the meson test. -J.
v15-0003-Extend-pg_buffercache-with-new-view-pg_buffercac.patch
Description: Binary data
v15-0001-Add-optional-dependency-to-libnuma-Linux-only-fo.patch
Description: Binary data
v15-0002-This-extracts-code-from-contrib-pg_buffercache-s.patch
Description: Binary data
v15-0004-Add-pg_shmem_numa_allocations-to-show-NUMA-memor.patch
Description: Binary data
