On Mon, Oct 24, 2016 at 9:34 PM, Tom Lane <t...@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. * These definitions are internal to fsmpage.c. */ #define NodesPerPage (BLCKSZ - MAXALIGN(SizeOfPageHeaderData) - \ offsetof(FSMPageData, fp_nodes)) #define NonLeafNodesPerPage (BLCKSZ / 2 - 1) #define LeafNodesPerPage (NodesPerPage - NonLeafNodesPerPage) /* * Number of FSM "slots" on a FSM page. This is what should be used * outside fsmpage.c. */ #define SlotsPerFSMPage LeafNodesPerPage Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services