Die Berechnung der Zeilengröße ist viel komplexer als das.
Der Speicher wird normalerweise in Datenseiten von 8 KB partitioniert . Es gibt einen kleinen festen Overhead pro Seite, mögliche Reste, die nicht groß genug sind, um in ein anderes Tupel zu passen, und, was noch wichtiger ist, tote Zeilen oder einen anfänglich mit dem FILLFACTOR reservierten Prozentsatz Einstellung.
Und es gibt noch mehr Overhead pro Zeile (Tupel):eine Elementkennung von 4 Bytes am Anfang der Seite, der HeapTupleHeader von 23 Byte und Alignment Padding . Der Anfang des Tupel-Headers sowie der Anfang der Tupel-Daten werden auf ein Vielfaches von MAXALIGN ausgerichtet , das sind 8 Byte auf einem typischen 64-Bit-Computer. Einige Datentypen erfordern eine Ausrichtung auf das nächste Vielfache von 2, 4 oder 8 Bytes.
Zitieren Sie das Handbuch zur Systemtabelle pg_tpye :
typalign ist die Ausrichtung, die beim Speichern eines Werts dieses Typs erforderlich ist. Sie gilt sowohl für die Speicherung auf der Festplatte als auch für die meisten Darstellungen des Werts in PostgreSQL. Wenn mehrere Werte nacheinander gespeichert werden, wie beispielsweise bei der Darstellung einer vollständigen Zeile auf der Platte, wird vor einem Datum dieses Typs eine Auffüllung eingefügt, so dass es an der angegebenen Grenze beginnt. Die Ausrichtungsreferenz ist der Anfang des ersten Datums in der Sequenz.
Mögliche Werte sind:
-
c=charAusrichtung, d. h. keine Ausrichtung erforderlich. -
s=shortAusrichtung (2 Bytes auf den meisten Maschinen). -
i=intAusrichtung (4 Bytes auf den meisten Maschinen). -
d=doubleAusrichtung (8 Bytes auf vielen Maschinen, aber keineswegs auf allen).
Lesen Sie hier mehr über die Grundlagen im Handbuch.
Dein Beispiel
Dies führt zu 4 Bytes Auffüllung nach Ihren 3 integer Spalten, da der timestamp Spalte erfordert double Ausrichtung und muss beim nächsten Vielfachen von 8 Bytes beginnen.
Eine Zeile belegt also:
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 Elementkennung pro Tupel im Seitenkopf (wie von @A.H. im Kommentar hervorgehoben):
+ 4 -- item identifier in page header
------
= 52 bytes
So kommen wir zu den beobachteten 52 Bytes .
Die Berechnung pg_relation_size(tbl) / count(*) ist eine pessimistische Schätzung. pg_relation_size(tbl) enthält aufgeblähte (tote Zeilen) und durch fillfactor reservierten Speicherplatz , sowie Overhead pro Datenseite und pro Tabelle. (Und wir haben die Komprimierung für lange varlena nicht einmal erwähnt Daten in TOAST-Tabellen, da es hier nicht zutrifft.)
Sie können das Zusatzmodul pgstattuple installieren und SELECT * FROM pgstattuple('tbl_name'); aufrufen für weitere Informationen zur Tabellen- und Tupelgröße.
Verwandte:
- Tabellengröße mit Seitenlayout
- Berechnen und Platz sparen in PostgreSQL
