Бих казал pg_column_size
отчита компресирания размер на TOAST
ed стойности, докато octet_length
отчита некомпресираните размери. Не съм проверил това чрез проверка на източника на функцията или дефинициите, но би имало смисъл, особено тъй като низовете от числа ще се компресират доста добре. Използвате EXTENDED
съхранение, така че стойностите да отговарят на условията за TOAST
компресия. Вижте TOAST
документация
.
Що се отнася до изчисляването на очаквания размер на DB, това е изцяло нов въпрос. Както можете да видите от следната демонстрация, това зависи от неща като това колко компресируеми са вашите низове.
Ето демонстрация, показваща как octet_length
може да бъде по-голям от pg_column_size
, демонстрирайки къде започва работа TOAST. Първо, нека получим резултатите при извеждане на заявка, където няма TOAST
влиза в действие:
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)
Сега нека съхраним този резултат от същата заявка в таблица и да получим размера на съхранените редове:
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)