Jeg vil sige pg_column_size rapporterer den komprimerede størrelse af TOAST ed værdier, mens octet_length rapporterer de ukomprimerede størrelser. Jeg har ikke bekræftet dette ved at kontrollere funktionskilden eller definitionerne, men det ville give mening, især da talstrenge vil komprimere ret godt. Du bruger EXTENDED lagring, så værdierne er kvalificerede til TOAST kompression. Se TOAST dokumentation
.
Hvad angår beregning af forventet DB-størrelse, er det et helt nyt spørgsmål. Som du kan se fra følgende demo, afhænger det af ting som f.eks. hvor komprimerbare dine strenge er.
Her er en demonstration, der viser hvordan octet_length kan være større end pg_column_size , der demonstrerer, hvor TOAST slår ind. Lad os først få resultaterne på forespørgselsoutput, hvor ingen TOAST kommer i spil:
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)
Lad os nu gemme det samme forespørgselsoutput i en tabel og få størrelsen på de lagrede rækker:
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)