Ich würde sagen pg_column_size meldet die komprimierte Größe von TOAST ed-Werte, während octet_length meldet die unkomprimierten Größen. Ich habe dies nicht überprüft, indem ich die Funktionsquelle oder Definitionen überprüft habe, aber es wäre sinnvoll, insbesondere da Zahlenfolgen recht gut komprimiert werden. Sie verwenden EXTENDED Speicherung, damit die Werte für TOAST geeignet sind Kompression. Siehe den TOAST Dokumentation
.
Die Berechnung der erwarteten DB-Größe ist eine ganz neue Frage. Wie Sie der folgenden Demo entnehmen können, hängt dies beispielsweise davon ab, wie komprimierbar Ihre Saiten sind.
Hier ist eine Demonstration, die zeigt, wie octet_length kann größer als pg_column_size sein , um zu demonstrieren, wo TOAST ansetzt. Lassen Sie uns zunächst die Ergebnisse der Abfrageausgabe abrufen, bei der kein TOAST vorhanden ist kommt ins Spiel:
regress=> SELECT octet_length(repeat('1234567890',(2^n)::integer)), pg_column_size(repeat('1234567890',(2^n)::integer)) FROM generate_series(0,12) n;
octet_length | pg_column_size
--------------+----------------
10 | 14
20 | 24
40 | 44
80 | 84
160 | 164
320 | 324
640 | 644
1280 | 1284
2560 | 2564
5120 | 5124
10240 | 10244
20480 | 20484
40960 | 40964
(13 rows)
Lassen Sie uns jetzt dieselbe Abfrageausgabe in einer Tabelle speichern und die Größe der gespeicherten Zeilen ermitteln:
regress=> CREATE TABLE blah AS SELECT repeat('1234567890',(2^n)::integer) AS data FROM generate_series(0,12) n;
SELECT 13
regress=> SELECT octet_length(data), pg_column_size(data) FROM blah;
octet_length | pg_column_size
--------------+----------------
10 | 11
20 | 21
40 | 41
80 | 81
160 | 164
320 | 324
640 | 644
1280 | 1284
2560 | 51
5120 | 79
10240 | 138
20480 | 254
40960 | 488
(13 rows)
