最准的sql方式是直接查pg_class并结合pg_size_pretty()函数：select pg_size_pretty(pg_total_relation_size('表名')) as total_size, pg_size_pretty(pg_relation_size('表名')) as data_size, pg_size_pretty(pg_indexes_size('表名')) as index_size；该方法实时计算，涵盖数据、索引及toast，精度远超relpages估算。
直接查 pg_class：PostgreSQL 表大小最准的 SQL 方式
Navicat 自带的“表属性”或“设计表”界面不显示物理大小，必须用 SQL 查询系统表。对 PostgreSQL，pg_class 是唯一可靠来源，它记录了每个表的 relpages（页数）和 reltuples（估算行数），再结合 pg_size_pretty() 才能转成可读单位。
在 Navicat 的查询窗口中执行：
SELECT pg_size_pretty(pg_total_relation_size('your_table_name')) AS total_size,
pg_size_pretty(pg_relation_size('your_table_name')) AS data_size,
pg_size_pretty(pg_indexes_size('your_table_name')) AS index_size;
-
pg_total_relation_size()包含数据 + 主键/索引 + TOAST 表（大字段存储区） -
pg_relation_size()仅主表数据（不含索引） -
pg_indexes_size()所有该表关联索引的总大小 - 把
'your_table_name'替换成实际表名，注意大小写敏感；若表名含小写或特殊字符，需加双引号，如"myTable"
别信“命令列界面”的中间那行输出
早期 Navicat 版本（如 12.x）的“命令列界面”确实会执行 \dt+ 并在输出中夹带一行大小信息，但这个值来自 pg_class.relpages * 8192 的粗略估算，不包含索引、TOAST 或 FSM/VACUUM 空闲空间，误差常达 20%～50%。2026 年主流版本（16+）已默认禁用该界面，或返回空结果。
如果你看到类似 Size: 128 kB 这样的输出，它只是基于页数的静态快照，不是实时磁盘占用，也不能反映 VACUUM 后释放的空间是否已被操作系统回收。
为什么不能右键表 → “属性”看大小？
Navicat 的“属性”面板只读取元数据（如创建时间、所有者、注释），不主动发起 pg_size_* 类函数调用。即使你右键表名 → “对象信息”，弹出框里也只显示逻辑信息（字段数、索引数、外键数），物理尺寸字段始终为空。
这是设计使然：Navicat 把“大小”视为运维级指标，而非开发级元数据，所以不缓存、不预加载、不图形化展示——避免在大型库上拖慢界面响应。
想批量查多张表？用系统视图拼接
单张表手动换名太麻烦，直接查 pg_tables 关联 pg_class：
SELECT schemaname, tablename,
pg_size_pretty(pg_total_relation_size(schemaname || '.' || tablename)) AS size
FROM pg_tables
WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
ORDER BY pg_total_relation_size(schemaname || '.' || tablename) DESC
LIMIT 10;
注意：schemaname || '.' || tablename 拼接后必须传给 pg_total_relation_size()，不能直接用字段别名；否则会报错 relation "xxx" does not exist —— 因为函数需要真实对象路径，不是字符串字面量。
这个查询结果里的 size 是实时计算的，但每次执行都会触发一次全表扫描式评估，对超大表（TB 级）可能卡顿几秒，别在高峰期反复刷。
真正影响你判断的，往往不是“怎么查”，而是查出来的数字到底代表什么：它不包括 WAL 日志、不包括归档备份、也不等于 du -sh 在文件系统看到的目录大小——因为 PostgreSQL 的共享缓冲区、检查点、后台写进程会让磁盘写入有延迟。如果发现 SQL 查出来 500MB，而磁盘上 base/ 目录占了 700MB，别慌，多出来的就是未刷盘的脏页和 WAL 缓冲。
