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
