Doubts regarding pg_freespacemap extension - Mailing list pgsql-hackers

From Rucha Kulkarni
Subject Doubts regarding pg_freespacemap extension
Date
Msg-id CAPsneqr4MYU+H21_PFzx3NQ+bjMuKr=38_hZexZHdJYUTToZPg@mail.gmail.com
Whole thread Raw
List pgsql-hackers

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

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Support POSITION with nondeterministic collations
Next
From: Jim Jones
Date:
Subject: Re: Missing [NO] INDENT flag in XMLSerialize backward parsing