Re: Add os_page_num to pg_buffercache

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Tomas Vondra <tomas@vondra.me>
Cc: Nathan Bossart <nathandbossart@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-01T17:20:06Z
Lists: pgsql-hackers
Hi,

On Tue, Jul 01, 2025 at 06:45:37PM +0200, Tomas Vondra wrote:
> On 7/1/25 18:34, Bertrand Drouvot wrote:
> 
> But isn't the _numa view good enough for this? Sure, you need NUMA
> support for it, and it may take a fair amount of time, but how often you
> need to do such queries?

Not that often, but my reasoning was more like:

why people managing engines and/or developing on platform that does not support
libnuma would not deserve access to this information?

> I don't plan to block improving this use case,

No worries at all, I do appreciate that you're looking at it and provide feedback
whatever the outcome would be.

> but I'm not sure it's worth the effort.

I think that the hard work has already been done while creating
pg_buffercache_numa_pages().

Now it's just a matter of extracting the necessary pieces from pg_buffercache_numa_pages()
so that:

* the new view could make use of it
* the maintenance burden should be low (thanks to code dedeuplication)
* people that don't have access to a platform that supports libnuma can have
access to this information

Regards,

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



Commits

  1. pg_buffercache: Add pg_buffercache_os_pages

  2. doc: Fix style of description for pg_buffercache_numa.os_page_num

  3. Add CHECK_FOR_INTERRUPTS in contrib/pg_buffercache functions.

  4. pg_walsummary: Improve stability of test checking statistics