Ik zou zeggen pg_column_size
meldt de gecomprimeerde grootte van TOAST
ed-waarden, terwijl octet_length
rapporteert de niet-gecomprimeerde formaten. Ik heb dit niet geverifieerd door de functiebron of definities te controleren, maar het zou logisch zijn, vooral omdat reeksen getallen vrij goed kunnen worden gecomprimeerd. Je gebruikt EXTENDED
opslag zodat de waarden in aanmerking komen voor TOAST
compressie. Zie de TOAST
documentatie
.
Wat betreft het berekenen van de verwachte DB-grootte, dat is een geheel nieuwe vraag. Zoals je in de volgende demo kunt zien, hangt het af van zaken als hoe samendrukbaar je snaren zijn.
Hier is een demonstratie die laat zien hoe octet_length
kan groter zijn dan pg_column_size
, om te laten zien waar TOAST van pas komt. Laten we eerst de resultaten bekijken over de uitvoer van zoekopdrachten waar geen TOAST
komt in het spel:
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)
Laten we nu dezelfde query-uitvoer opslaan in een tabel en de grootte van de opgeslagen rijen krijgen:
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)