From: | Mircea Cadariu <cadariu(dot)mircea(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
Subject: | Re: Add os_page_num to pg_buffercache |
Date: | 2025-07-08 14:47:34 |
Message-ID: | 175198605428.2200286.1834083775416059672.pgcf@coridan.postgresql.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation: tested, passed
Hi Bertrand,
Just tried out your patch, nice work, thought to leave a review as well.
Patch applied successfully on top of commit a27893df4 in master.
Ran the tests in pg_buffercache and they pass including the new ones.
Running "pagesize" on my laptop returns 16384.
test=# SELECT current_setting('block_size');
current_setting
-----------------
8192
(1 row)
Given the above, the results are as expected:
test=# select * from pg_buffercache_os_pages;
bufferid | os_page_num
----------+-------------
1 | 0
2 | 0
3 | 1
4 | 1
5 | 2
6 | 2
I have noticed that pg_buffercache_os_pages would be the 3rd function
which follows the same high-level structure (others being pg_buffercache_pages
and pg_buffercache_numa_pages). I am wondering if this would be let's say
"strike three" - time to consider extracting out a high-level "skeleton" function,
with a couple of slots which would then be provided by the 3 variants.
Kind regards,
Mircea
The new status of this patch is: Waiting on Author
From | Date | Subject | |
---|---|---|---|
Next Message | Matheus Alcantara | 2025-07-08 15:20:54 | Re: POC: Parallel processing of indexes in autovacuum |
Previous Message | Florents Tselai | 2025-07-08 14:40:39 | Re: mention unused_oids script in pg_proc.dat |