Yo diría pg_column_size informa el tamaño comprimido de TOAST ed valores, mientras que octet_length está informando los tamaños sin comprimir. No he verificado esto comprobando el origen de la función o las definiciones, pero tendría sentido, especialmente porque las cadenas de números se comprimirán bastante bien. Estás usando EXTENDED almacenamiento para que los valores sean elegibles para TOAST compresión. Consulte el TOAST documentación
.
En cuanto a calcular el tamaño esperado de DB, esa es una pregunta completamente nueva. Como puede ver en la siguiente demostración, depende de qué tan comprimibles sean sus cadenas.
Aquí hay una demostración que muestra cómo octet_length puede ser más grande que pg_column_size , demostrando dónde se activa TOAST. Primero, obtengamos los resultados en la salida de la consulta donde no hay TOAST entra en juego:
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)
Ahora almacenemos esa misma salida de consulta en una tabla y obtengamos el tamaño de las filas almacenadas:
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)
