Hi,
On Thu, Nov 20, 2025 at 04:59:07PM +0000, Bertrand Drouvot wrote:
> On Wed, Nov 19, 2025 at 10:49:49PM +0900, Michael Paquier wrote:
> >
> > 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!
Here they are:
0001:
Is nothing but the same as the one shared in [1].
0002:
Introduce GET_MAX_BUFFER_ENTRIES and get_buffer_page_boundaries
It's not really needed anymore since we'll avoid code duplication with the
new approach. That said I think they help for code readability so keeping them
(I don't have a strong opinion about it if other prefer not to add them).
0003:
Adding pg_buffercache_numa_pages_internal()
This new function makes NUMA data collection conditional.
It extracts the core current pg_buffercache_numa_pages() logic into an
internal function that accepts a boolean parameter. It's currently only called
with the boolean set to true to serve the pg_buffercache_numa view needs.
It's done that way to ease to review but could be pushed as is.
0004:
Add pg_buffercache_os_pages function and view
The patch:
- renames pg_buffercache_numa_pages_internal() to pg_buffercache_os_pages()
- keep pg_buffercache_numa_pages() as a backward compatibility wrapper
- re-create the pg_buffercache_numa view on top of pg_buffercache_os_pages using
true as argument
- adds doc
- adds test
Remark for the doc: the patch does not show the pg_buffercache_os_pages() parameter.
It just mentions that it exists. I think that's fine given that a) the same is
true for pg_buffercache_evict() and pg_buffercache_evict_relation() (maybe that
should be changed though), b) the only purpose of this function is to be linked
to the pg_buffercache_os_pages and pg_buffercache_numa views.
[1]: https://www.postgresql.org/message-id/aSBOKX6pLJzumbmF%40ip-10-97-1-34.eu-west-3.compute.internal
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
