On Wed, Nov 19, 2025 at 09:28:09AM +0000, Bertrand Drouvot wrote: > Option 1: > > We could simply create the pg_buffercache_os_pages view on top of the > pg_buffercache_numa one. The cons I can think of is that, when numa is > available, > then pg_buffercache_os_pages would pay the extra cost that also make > pg_buffercache_numa slow. > > Then there is no real benefits for adding a new view, we could just keep > pg_buffercache_numa and fill numa_node with NULLs if numa is not available and > document also the use case (with an example) when numa is not available. > > That would achieve the main goal. > > Option 2: > > Still make changes in pg_buffercache_numa_pages() and fill with NULL when > numa is not available. Then create an helper to do the mapping buffers to OS > pages without any NUMA specific operations. > > That way we could create a dedicated view pg_buffercache_os_pages on top of > a new function. No code duplication and the new view would not get the extra > cost if numa is available.
Hmm. I can think about an option 3 here: pg_buffercache outlines the view pg_buffercache_numa as the primary choice over pg_buffercache_numa_pages(). So I would suggest a more drastic strategy, that should not break monitoring queries with the views being the primary source for the results: - Rename of pg_buffercache_numa_pages() to pg_buffercache_os_pages(), that takes in input a boolean argument to decide if numa should be executed or not. - Creation of a second view for the OS pages that calls pg_buffercache_os_pages() without the numa code activated, for the two attributes that matter. - Switch the existing view pg_buffercache_numa to call pg_buffercache_os_pages() with the numa code activated. If NUMA cannot be set up, elog(ERROR). -- Michael
signature.asc
Description: PGP signature
