Powiedziałbym pg_column_size zgłasza skompresowany rozmiar TOAST ed wartości, natomiast octet_length zgłasza nieskompresowane rozmiary. Nie zweryfikowałem tego, sprawdzając źródło funkcji lub definicje, ale miałoby to sens, zwłaszcza że ciągi liczb kompresują się całkiem dobrze. Używasz EXTENDED przechowywania, więc wartości kwalifikują się do TOAST kompresja. Zobacz TOAST dokumentacja
.
Jeśli chodzi o obliczanie oczekiwanego rozmiaru DB, to zupełnie nowe pytanie. Jak widać na poniższym demo, zależy to od takich rzeczy, jak ściśliwość struny.
Oto demonstracja pokazująca, jak octet_length może być większy niż pg_column_size , pokazując, gdzie zaczyna się TOAST. Najpierw zdobądźmy wyniki na wyjściu zapytania, gdzie nie ma TOAST wchodzi w grę:
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)
Teraz zapiszmy ten sam wynik zapytania w tabeli i uzyskajmy rozmiar przechowywanych wierszy:
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)
