Řekl bych pg_column_size
hlásí komprimovanou velikost TOAST
ed, zatímco octet_length
hlásí nekomprimované velikosti. Neověřil jsem to kontrolou zdroje funkcí nebo definic, ale dávalo by to smysl, zvláště když se řetězce čísel docela dobře komprimují. Používáte EXTENDED
úložiště, takže hodnoty jsou vhodné pro TOAST
komprese. Viz TOAST
dokumentaci
.
Pokud jde o výpočet očekávané velikosti DB, to je zcela nová otázka. Jak můžete vidět z následující ukázky, závisí to na věcech, jako jsou komprimovatelné struny.
Zde je ukázka, jak octet_length
může být větší než pg_column_size
, což ukazuje, kde se TOAST začíná projevovat. Nejprve získáme výsledky na výstupu dotazu, kde není TOAST
přichází do hry:
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)
Nyní uložme stejný výstup dotazu do tabulky a získáme velikost uložených řádků:
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)