我正在使用9.1，并且在UTF-8编码的数据库中有一个名为dpi的表格，当前坐标为18,628行。 那里有一个叫做foto的TEXT列，它保存代表唯一图像文件的B64string。
我想弄清楚一行需要多less磁盘空间。 有18050行与非NULL值的foto和length()为所有他们是87384。
我没有得到的是这个。 运行select * from pgstattuple('dpi'); 收益：
-[ RECORD 1 ]------+-------- table_len | 5890048 tuple_count | 18628 tuple_len | 5656063 tuple_percent | 96.03 dead_tuple_count | 0 dead_tuple_len | 0 dead_tuple_percent | 0 free_space | 92752 free_percent | 1.57
运行
select pg_size_pretty(pg_relation_size(c.oid)) AS "size" from pg_class c where relname = 'dpi';
我得到以下内容：
size --------- 5752 kB (1 row)
这到底是怎么回事？ 为什么这个桌子这么小？
编辑：另外，我检查了/var/lib/postgresql/9.1/main和它措施574.5MiB。 运行：
SELECT nspname || '.' || relname AS "relation", pg_size_pretty(pg_relation_size(C.oid)) AS "size" FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT IN ('pg_catalog', 'information_schema') ORDER BY pg_relation_size(C.oid) DESC LIMIT 3;
收益率：
relation | size -------------------------------+--------- pg_toast.pg_toast_17048 | 501 MB public.dpi | 5752 kB pg_toast.pg_toast_17048_index | 5752 kB (3 rows)
编辑2：使用select pg_total_relation_size('dpi'); 我得到539262976字节。 这是否意味着我可以把它除以18628，这会给我每行的平均大小（28 KiB）？ 每行的大小是否随时间变化（因为索引或类似的）？
即便如此，每行28 KiB似乎特别小。 一个foto值应该是85 KiB（假设只有1个字节的字符）。
答案是PostgreSQL的TOAST机制在默认情况下不仅会分割非常大的列，而且还取决于数据types，它实际上会首先压缩它们。 很简约。
资料来源： http ： //www.postgresql.org/docs/9.1/static/storage-toast.html
Postgresql没有“blobtypes”。 会发生什么，它会自动切片“大列”（即大于1页，8K）到“敬酒”表。
在这里查看关于postgres上磁盘使用情况的信息
在这里为postgresqlpipe理function ，你会发现你感兴趣的function是： pg_table_size和pg_total_relation_size
两者都考虑到吐司空间。 第一个不算索引空间，第二个不算。