On Mon, Oct 24, 2016 at 9:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
SELECT blkno, pg_freespace(oid::regclass, blkno) FROM generate_series(pg_relation_size(oid::regclass) / current_setting('block_size')::BIGINT, pg_relation_size(oid::regclass, 'fsm') / 2) AS blkno
It looks to me like this is approximating the highest block number that could possibly have an FSM entry as size of the FSM fork (in bytes) divided by 2. But the FSM stores one byte per block. There is overhead for the FSM search tree, but in a large relation it's not going to be as much as a factor of 2. So I think that to be conservative we need to drop the "/ 2". Am I missing something?
I went by these comments in fsm_internals.h, which suggest that the SlotsPerFSMPage are limited to somewhat less than BLCKSZ divided by 2.
/*
* Number of non-leaf and leaf nodes, and nodes in total, on an FSM page.
