| From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Mircea Cadariu <cadariu(dot)mircea(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Add os_page_num to pg_buffercache |
| Date: | 2025-11-21 11:53:52 |
| Message-ID: | aSBS0KdjlUXAl8d1@ip-10-97-1-34.eu-west-3.compute.internal |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| v8-0001-Remove-unused-fields-from-BufferCacheNumaRec.patch | text/x-diff | 2.0 KB |
| v8-0002-Introduce-GET_MAX_BUFFER_ENTRIES-and-get_buffer_p.patch | text/x-diff | 3.5 KB |
| v8-0003-Adding-pg_buffercache_numa_pages_internal.patch | text/x-diff | 9.1 KB |
| v8-0004-Add-pg_buffercache_os_pages-function-and-view.patch | text/x-diff | 20.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2025-11-21 12:13:50 | Re: 10% drop in code line count in PG 17 |
| Previous Message | Rahila Syed | 2025-11-21 11:45:35 | Segmentation fault on proc exit after dshash_find_or_insert |