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


 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Reply via email to