Eu diria
pg_column_size está relatando o tamanho compactado de TOAST valores ed, enquanto octet_length está relatando os tamanhos não compactados. Eu não verifiquei isso verificando a fonte ou as definições da função, mas faria sentido, especialmente porque as sequências de números serão compactadas muito bem. Você está usando EXTENDED armazenamento para que os valores sejam qualificados para TOAST compressão. Veja o TOAST documentação
. Quanto ao cálculo do tamanho esperado do banco de dados, essa é uma questão totalmente nova. Como você pode ver na demonstração a seguir, depende de coisas como quão compressíveis são suas strings.
Aqui está uma demonstração mostrando como
octet_length pode ser maior que pg_column_size , demonstrando onde o TOAST entra em ação. Primeiro, vamos obter os resultados na saída da consulta onde não há TOAST entra em jogo: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)
Agora vamos armazenar a mesma saída de consulta em uma tabela e obter o tamanho das linhas armazenadas:
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)
