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)