Obliczanie rozmiaru wiersza jest znacznie bardziej złożone.
Pamięć jest zwykle podzielona na 8 kB strony danych . Istnieje mały stały narzut na stronę, możliwe pozostałości nie są wystarczająco duże, aby zmieścić inną krotkę, a co ważniejsze, martwe wiersze lub procent początkowo zarezerwowany za pomocą FILLFACTOR ustawienie.
I jest jeszcze więcej narzutu na rząd (krotka):identyfikator pozycji o długości 4 bajtów na początku strony, HeapTupleHeader 23 bajtów i dopełnienie wyrównania . Początek nagłówka krotki oraz początek danych krotki są wyrównane do wielokrotności MAXALIGN , czyli 8 bajtów na typowej maszynie 64-bitowej. Niektóre typy danych wymagają wyrównania do następnej wielokrotności 2, 4 lub 8 bajtów.
Cytując instrukcję w tabeli systemowej pg_tpye :
typalign jest wyrównaniem wymaganym podczas przechowywania wartości tego typu. Dotyczy to przechowywania na dysku, a także większości reprezentacji wartości w PostgreSQL. Gdy wiele wartości jest przechowywanych kolejno, na przykład w reprezentacji pełnego wiersza na dysku, dopełnienie jest wstawiane przed daną tego typu, tak aby zaczynała się na określonej granicy. Odniesienie do wyrównania jest początkiem pierwszego punktu odniesienia w sekwencji.
Możliwe wartości to:
-
c=charwyrównanie, tj. nie jest potrzebne wyrównanie. -
s=shortwyrównanie (2 bajty na większości maszyn). -
i=intwyrównanie (4 bajty na większości maszyn). -
d=doublewyrównanie (8 bajtów na wielu komputerach, ale nie na wszystkich).
Przeczytaj o podstawach w instrukcji tutaj.
Twój przykład
Daje to 4 bajty dopełnienia po 3 integer kolumny, ponieważ timestamp kolumna wymaga double wyrównanie i musi zaczynać się od następnej wielokrotności 8 bajtów.
Tak więc jeden rząd zajmuje:
23 -- heaptupleheader
+ 1 -- padding or NULL bitmap
+ 12 -- 3 * integer (no alignment padding here)
+ 4 -- padding after 3rd integer
+ 8 -- timestamp
+ 0 -- no padding since tuple ends at multiple of MAXALIGN
Plus identyfikator elementu na krotkę w nagłówku strony (jak wskazuje @A.H. w komentarzu):
+ 4 -- item identifier in page header
------
= 52 bytes
Dochodzimy więc do zaobserwowanych 52 bajtów .
Obliczenie pg_relation_size(tbl) / count(*) to pesymistyczna ocena. pg_relation_size(tbl) zawiera wzdęcia (martwe wiersze) i miejsce zarezerwowane przez fillfactor , a także narzut na stronę danych i na tabelę. (I nawet nie wspomnieliśmy o kompresji dla długich varlena dane w tabelach TOAST, ponieważ nie mają tu zastosowania.)
Możesz zainstalować dodatkowy moduł pgstattuple i wywołać SELECT * FROM pgstattuple('tbl_name'); aby uzyskać więcej informacji na temat rozmiaru tabeli i krotki.
Powiązane:
- Rozmiar tabeli z układem strony
- Obliczanie i oszczędzanie miejsca w PostgreSQL
