Doubts regarding pg_freespacemap extension

From: Rucha Kulkarni <rirukool(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Doubts regarding pg_freespacemap extension
Date: 2025-02-17 15:12:15
Message-ID: CAPsneqqHWWb4RxBFeViZAVx-CBMECinVTvQzrc6H7169Zay9Bw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi PostgreSQL Community,

While exploring the pg_freespacemap extension, I came across a few doubts
and would appreciate any insights or clarifications:

1. In the code, it defines NonLeafNodesPerPage as (BLCKSZ / 2 - 1) as can
be seen here:

https://github.com/postgres/postgres/blob/master/src/include/storage/fsm_internals.h#L54

For a binary tree, (BLCKSZ - 1) / 2 seems more appropriate when calculating
the number of non-leaf nodes. Why does the code approximate it to (BLCKSZ /
2) - 1 ?

2. According to the comment mentioned here
https://github.com/postgres/postgres/blob/master/src/backend/storage/freespace/indexfsm.c#L19
, 0 is used to denote unused pages and (BLCKSZ - 1) for used pages for
indexes. This seems reversed, shouldn't 0 indicate space available for used
pages, and (BLCKSZ - 1) indicate space available for unused pages?

3. Whenever I check the values for B-tree indexes, I observe all values to
be 0.

postgres=# select * from pg_freespace('xyz_btree');
blkno | avail
-------+-------
0 | 0
1 | 0
2 | 0
3 | 0
4 | 0
(5 rows)

How can non-zero values be observed in B-tree indexes?

4. For BRIN indexes, I see a value of 8128 instead of 8191 (BLCKSZ - 1). Is
this due to the BRIN header occupying space, leading to category 254?

postgres=# select * from pg_freespace('xyz_brin');
blkno | avail
-------+-------
0 | 0
1 | 0
2 | 8128
(3 rows)

Regards,

Rucha Kulkarni

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Doron Tsur 2025-02-17 16:04:57 Re: The performance issues caused by upgrading PostgreSQL to version 16.3.
Previous Message Greg Sabino Mullane 2025-02-17 14:22:50 Re: The performance issues caused by upgrading PostgreSQL to version 16.3.