Hi,
On Fri, Nov 21, 2025 at 11:53:52AM +0000, Bertrand Drouvot wrote:
> 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:
Attached a rebase due to 7d9043aee80. Also 0003 has a minor change (as compared
to v8-0004) to avoid this error when creating the 1.6 version with the new code:
postgres=# create extension pg_buffercache version '1.6';
CREATE EXTENSION
postgres=# select count(*) from pg_buffercache_numa;
ERROR: set-valued function called in context that cannot accept a set
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com