On 4/10/25 15:17, Bertrand Drouvot wrote:
> Hi hackers,
>
> I was doing some more tests around ba2a3c2302f (pg_buffercache_numa) and
> thought that seeing how buffers are spread across multiple OS pages (if that's
> the case) thanks to the os_page_num field is good information to have.
>
> The thing that I think is annoying is that to get this information (os_page_num):
>
> - One needs to use pg_buffercache_numa (which is more costly/slower) than pg_buffercache
> - One needs a system with NUMA support enabled
>
> So why not also add this information (os_page_num) in pg_buffercache?
>
> - It would make this information available on all systems, not just NUMA-enabled ones
> - It would help understand the memory layout implications of configuration changes
> such as database block size, OS page size (huge pages for example) and see how the
> buffers are spread across OS pages (if that's the case).
>
> So, please find attached a patch to $SUBJECT then.
>
> Remarks:
>
> - Maybe we could create a helper function to reduce the code duplication between
> pg_buffercache_pages() and pg_buffercache_numa_pages()
> - I think it would have made sense to also add this information while working
> on ba2a3c2302f but (unfortunately) I doubt that this patch is candidate for v18
> post freeze (it looks more a feature enhancement than anything else)
> - It's currently doing the changes in pg_buffercache v1.6 but will need to
> create v1.7 for 19 (if the above stands true)
>
This seems like a good idea in principle, but at this point it has to
wait for PG19. Please add it to the July commitfest.
regards
--
Tomas Vondra
