Re: Add os_page_num to pg_buffercache - Mailing list pgsql-hackers

From Mircea Cadariu
Subject Re: Add os_page_num to pg_buffercache
Date
Msg-id 175198605428.2200286.1834083775416059672.pgcf@coridan.postgresql.org
Whole thread Raw
In response to Add os_page_num to pg_buffercache  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: [PATCH] Support for basic ALTER TABLE progress reporting.
Next
From: "Matheus Alcantara"
Date:
Subject: Re: POC: Parallel processing of indexes in autovacuum