Re: Add os_page_num to pg_buffercache

Hi,

On Wed, Nov 19, 2025 at 10:49:49PM +0900, Michael Paquier wrote:
> 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).

Love the idea: the new view would not suffer from the numa availability overhead
and the current behavior is kept. Will look at it, thanks!

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com