Re: [HACKERS] pgstattuple documentation clarification - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] pgstattuple documentation clarification
Date
Msg-id 30516.1482246116@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] pgstattuple documentation clarification  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [HACKERS] pgstattuple documentation clarification  (Andrew Dunstan <andrew@dunslane.net>)
Re: [HACKERS] pgstattuple documentation clarification  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Recently a client was confused because there was a substantial 
> difference between the reported table_len of a table and the sum of the 
> corresponding tuple_len, dead_tuple_len and free_space. The docs are 
> fairly silent on this point, and I agree that in the absence of 
> explanation it is confusing, so I propose that we add a clarification 
> note along the lines of:

>     The table_len will always be greater than the sum of the tuple_len,
>     dead_tuple_len and free_space. The difference is accounted for by
>     page overhead and space that is not free but cannot be attributed to
>     any particular tuple.

> Or perhaps we should be more explicit and refer to the item pointers on 
> the page.

I find "not free but cannot be attributed to any particular tuple"
to be entirely useless weasel wording, not to mention wrong with
respect to item pointers in particular.

Perhaps we should start counting the item pointers in tuple_len.
We'd still have to explain about page header overhead, but that
would be a pretty small and fixed-size discrepancy.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [HACKERS] Quorum commit for multiple synchronous replication.
Next
From: Fujii Masao
Date:
Subject: Re: [HACKERS] Proposal for changes to recovery.conf API