On 12/20/2016 10:01 AM, Tom Lane wrote:
Andrew Dunstan <and...@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.
Well, the reason I put it like that was that in my experimentation,
after I vacuumed the table after a large delete the item pointer table
didn't seem to shrink (at least according to the pgstattuple output), so
we had a page with 0 dead tuples but some non-live line pointer space.
If that's not what's happening then something is going on that I don't
understand. (Wouldn't be a first.)
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.
Sure, sounds like a good idea. Meanwhile it would be nice to explain to
people exactly what we currently have. If you have a good formulation
I'm all ears.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
