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
