On Tue, Mar 4, 2025 at 5:02 PM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote:
> > Cool! Attached is v7 > Thanks for the new version! ... and another one: 7b ;) > > > === 2 [..] > > Well, I've made query_numa a parameter there simply to avoid that code > > duplication in the first place, look at those TupleDescInitEntry()... > > Yeah, that's why I was mentioning to use a "shared" > populate_buffercache_entry() > or such function: to put the "duplicated" code in it and then use this > shared function in pg_buffercache_pages() and in the new numa related one. OK, so hastily attempted that in 7b , I had to do a larger refactor there to avoid code duplication between those two. I don't know which attempt is better though (7 vs 7b).. > > IMHO rarely anybody uses pg_buffercache, but we could add unlikely() > > I think unlikely() should be used for optimization based on code path > likelihood, > not based on how often users might use a feature. In 7b I've removed the unlikely() - For a moment I was thinking that you are concerned about this loop for NBuffers to be as much optimized as it can and that's the reason for splitting the routines. > > > === 5 [..] > I meant to say avoid code duplication between pg_get_shmem_allocations() and > pg_get_shmem_numa_allocations(). It might be possible to create a shared > function for them too. That said, it looks like that the savings (if any), > would > not be that much, so maybe just forget about it. Yeah, OK, so let's leave it at that. -J.
v7b-0003-Add-pg_shmem_numa_allocations-to-show-NUMA-zones.patch
Description: Binary data
v7b-0002-Extend-pg_buffercache-with-new-view-pg_buffercac.patch
Description: Binary data
v7b-0001-Add-optional-dependency-to-libnuma-Linux-only-fo.patch
Description: Binary data
