Re: Add os_page_num to pg_buffercache
От | Tomas Vondra |
---|---|
Тема | Re: Add os_page_num to pg_buffercache |
Дата | |
Msg-id | f69a708a-870b-4124-ace7-bca57bd6c494@vondra.me обсуждение исходный текст |
Ответ на | Add os_page_num to pg_buffercache (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: Add os_page_num to pg_buffercache
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: