Re: Add os_page_num to pg_buffercache
| От | Bertrand Drouvot |
|---|---|
| Тема | Re: Add os_page_num to pg_buffercache |
| Дата | |
| Msg-id | aSBS0KdjlUXAl8d1@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
| Ответ на | Re: Add os_page_num to pg_buffercache (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
| Ответы |
Re: Add os_page_num to pg_buffercache
|
| Список | 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
Вложения
В списке pgsql-hackers по дате отправления: