Direi pg_column_size
sta segnalando la dimensione compressa di TOAST
ed valori, mentre octet_length
sta segnalando le dimensioni non compresse. Non l'ho verificato controllando l'origine o le definizioni della funzione, ma avrebbe senso, soprattutto perché le stringhe di numeri si comprimeranno abbastanza bene. Stai usando EXTENDED
archiviazione in modo che i valori siano idonei per TOAST
compressione. Vedi il TOAST
documentazione
.
Per quanto riguarda il calcolo della dimensione prevista del DB, questa è una domanda completamente nuova. Come puoi vedere dalla seguente demo, dipende da cose come la comprimibilità delle tue stringhe.
Ecco una dimostrazione che mostra come octet_length
può essere più grande di pg_column_size
, dimostrando dove entra in gioco TOAST. Per prima cosa, otteniamo i risultati sull'output della query dove nessun TOAST
entra in gioco:
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)
Ora memorizziamo lo stesso output della query in una tabella e otteniamo la dimensione delle righe archiviate:
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)