COUNT(*)慢因全表扫描，pg_class.reltuples可快速估算行数，需ANALYZE更新统计信息，分区表需递归求和，适用于监控等非精确场景。
在PostgreSQL中，精确统计表的行数（COUNT(*)）在大表上会很慢，因为需要扫描整个表。但很多时候我们只需要一个大致的行数估算，这时可以通过系统表快速获取近似值。
为什么COUNT(*)很慢？
执行 COUNT(*) 时，PostgreSQL必须遍历所有可见行（考虑事务可见性），尤其是没有索引或表很大的情况下，会造成全表扫描，性能开销大。
使用系统表估算行数
PostgreSQL的优化器本身会维护表的统计信息，这些信息存储在 pg_class 系统表中，其中 reltuples 字段就是对表行数的动态估算值。
查询方式如下：
SELECT reltuples AS estimate_countFROM pg_class
WHERE relname = 'your_table_name';
注意：reltuples 是浮点数，表示当前表的估算行数，由 ANALYZE 命令更新。如果最近没运行过 ANALYZE，数据可能不准确。
提高估算准确度的方法
确保统计信息最新是关键。可以手动触发分析：
ANALYZE your_table_name;
之后再查 pg_class.reltuples，结果会更接近实际值。对于频繁变更的表，建议定期运行 ANALYZE。
结合TOAST表和分区表的注意事项
如果表有TOAST表或使用了分区，pg_class.reltuples 只反映主表估算。如需整体估算，可递归查询分区：
FROM pg_class
WHERE relname IN (
SELECT inhrelname
FROM pg_inherits
JOIN pg_class ON inhparent = pg_class.oid
WHERE relname = 'your_partitioned_table'
);
对比：精确 vs 估算
-
精确计数：使用
SELECT COUNT(*) FROM table;—— 准确但慢 -
快速估算：使用
pg_class.reltuples—— 快但可能略有偏差
根据业务场景选择：监控、展示趋势用估算足够；审计、校验等需精确值则仍需 COUNT。
基本上就这些。合理利用系统统计信息，能大幅降低大表行数查询的开销。
