From: | Tomas Vondra <tomas(at)vondra(dot)me> |
---|---|
To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add os_page_num to pg_buffercache |
Date: | 2025-04-10 13:35:24 |
Message-ID: | f69a708a-870b-4124-ace7-bca57bd6c494@vondra.me |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2025-04-10 13:50:36 | Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions |
Previous Message | Robert Haas | 2025-04-10 13:31:00 | Re: pgsql: Add function to get memory context stats for processes |