Re: Add os_page_num to pg_buffercache
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Mircea Cadariu <cadariu.mircea@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-11-21T11:53:52Z
Lists: pgsql-hackers
Attachments
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
Commits
-
pg_buffercache: Add pg_buffercache_os_pages
- 4b203d499c61 19 (unreleased) landed
-
doc: Fix style of description for pg_buffercache_numa.os_page_num
- fce13424b9c5 19 (unreleased) landed
-
Add CHECK_FOR_INTERRUPTS in contrib/pg_buffercache functions.
- eab9e4e27c0c 19 (unreleased) cited
-
pg_walsummary: Improve stability of test checking statistics
- a27893df45ec 19 (unreleased) cited