Je dirais pg_column_size signale la taille compressée de TOAST ed valeurs, tandis que octet_length signale les tailles non compressées. Je n'ai pas vérifié cela en vérifiant la source de la fonction ou les définitions, mais cela aurait du sens, d'autant plus que les chaînes de nombres se compriment assez bien. Vous utilisez EXTENDED stockage afin que les valeurs soient éligibles pour TOAST compression. Voir le TOAST documents
.
Quant au calcul de la taille de base de données attendue, c'est une toute nouvelle question. Comme vous pouvez le voir dans la démo suivante, cela dépend de choses comme la compressibilité de vos cordes.
Voici une démonstration montrant comment octet_length peut être supérieur à pg_column_size , démontrant où TOAST entre en jeu. Tout d'abord, obtenons les résultats sur la sortie de la requête où aucun TOAST entre en jeu :
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)
Stockons maintenant cette même sortie de requête dans une table et obtenons la taille des lignes stockées :
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)
