Thread: HeapTupleHeaderData Layout description
Hi,
In https://www.postgresql.org/docs/13/storage-page-layout.html
we can find on § 68.6.1. Table Row Layout
the Table 68.4. HeapTupleHeaderData Layout
When additionning Length of differents Fields taht are present we obtain atotal of
4+4+4+4+6+2+2+1 = 27
What doesn't seem to fit with previous indication "There is a fixed-size header (occupying 23 bytes on most machines)"
Researching in old doc shows that in 8.2 the documentation
https://www.postgresql.org/docs/8.2/storage-page-layout.html
indicate 27 bytes (with the same detailled Table)
Number 23 appears from Postgres 8.3
In some thread like https://stackoverflow.com/questions/2966524/calculating-and-saving-space-in-postgresql/7431468
It's possible to read that
Overhead per tuple (row)
... And at least 24 bytes (23 + padding) for the tuple header ...
As there is several thread about this point I suppose there is an evolution between 8.2 and 8.3 with a missdocumentation for an evolution of detailled Table "HeapTupleHeaderData Layout"
IS it right ? And in this case what is the real detailled Table ?
Thanks for any explanations
Regards
In https://www.postgresql.org/docs/13/storage-page-layout.html
we can find on § 68.6.1. Table Row Layout
the Table 68.4. HeapTupleHeaderData Layout
When additionning Length of differents Fields taht are present we obtain atotal of
4+4+4+4+6+2+2+1 = 27
What doesn't seem to fit with previous indication "There is a fixed-size header (occupying 23 bytes on most machines)"
Researching in old doc shows that in 8.2 the documentation
https://www.postgresql.org/docs/8.2/storage-page-layout.html
indicate 27 bytes (with the same detailled Table)
Number 23 appears from Postgres 8.3
In some thread like https://stackoverflow.com/questions/2966524/calculating-and-saving-space-in-postgresql/7431468
It's possible to read that
Overhead per tuple (row)
... And at least 24 bytes (23 + padding) for the tuple header ...
As there is several thread about this point I suppose there is an evolution between 8.2 and 8.3 with a missdocumentation for an evolution of detailled Table "HeapTupleHeaderData Layout"
IS it right ? And in this case what is the real detailled Table ?
Thanks for any explanations
Regards
benj.dev@laposte.net writes: > In https://www.postgresql.org/docs/13/storage-page-layout.html<br> > we can find on § 68.6.1. Table Row Layout<br> > the Table 68.4. HeapTupleHeaderData Layout<br> > <br> > When additionning Length of differents Fields taht are present we obtain atotal of<br> > 4+4+4+4+6+2+2+1 = 27<br> I think you missed the point that t_cid overlays with t_xvac. regards, tom lane
Le 22/01/2021 à 17:49, Tom Lane a écrit : > benj.dev@laposte.net writes: >> In https://www.postgresql.org/docs/13/storage-page-layout.html<br> >> we can find on § 68.6.1. Table Row Layout<br> >> the Table 68.4. HeapTupleHeaderData Layout<br> >> <br> >> When additionning Length of differents Fields taht are present we obtain atotal of<br> >> 4+4+4+4+6+2+2+1 = 27<br> > > I think you missed the point that t_cid overlays with t_xvac. > > regards, tom lane > Hi, Thank you for this point. It's more clear. So in fact the error (with number 27) was in the documentation for version before postgres 8.3. In version >=8.3, the overlays precision could be added into sentence "XID for VACUUM operation moving a row version" => "XID for VACUUM operation moving a row version (overlays with t_cid)" or Maybe show t_cid and t_xvac in the same cell into the array could be more clear Example : |===========|===============|=========|================================| |Field |Type |Length |Description | |===========|===============|=========|================================| |t_xmin |TransactionId |4 octets |insert XID stamp | |-----------|---------------|---------|--------------------------------| |t_xmax |TransactionId |4 octets |delete XID stamp | |-----------|---------------|---------|--------------------------------| |t_cid |CommandId | |insert and/or delete CID stamp | |t_xvac |TransactionId | |XID for VACUUM operation moving | | | | |a row version | | | |4 octets |(t_cid and t_xvax are overlayed)| |-----------|---------------|---------|--------------------------------| |t_ctid |ItemPointerData|6 octets |current TID of this or newer row| | | | |version | |-----------|---------------|---------|--------------------------------| |t_infomask2|uint16 |2 octets |number of attributes, plus | | | | |various flag bits | |-----------|---------------|---------|--------------------------------| |t_infomask |uint16 |2 octets |various flag bits | |-----------|---------------|---------|--------------------------------| |t_hoff |uint8 |1 octet |offset to user data | |===========|===============|=========|================================| Thanks, Regards
benj.dev@laposte.net writes:
> Le 22/01/2021 à 17:49, Tom Lane a écrit :
>> I think you missed the point that t_cid overlays with t_xvac.
> So in fact the error (with number 27) was in the documentation for
> version before postgres 8.3.
No, the pre-8.3 docs are also correct, for their time.
regards, tom lane