PostgreSQL数据库大小不合理

在我的postgresql 9.6实例中，我有一个生产数据库。当我查询所有数据库的大小时：

combit=> Select pg_database.datname,pg_size_pretty(pg_database_size(pg_database.datname)) as size from pg_database;
  datname  |  size   
-----------+---------
 template0 | 7265 kB
 combit    | 285 GB
 postgres  | 7959 kB
 template1 | 7983 kB
 repmgr    | 8135 kB
(5 rows)

当我检查数据库中的大表（包括索引）时：

[/data/base]：

16400是combit数据库的oid。如您所见，fs上combit的尺寸约为298G

我在最大的表中检查了死元组：

combit=>select relname,n_dead_tup,last_autoanalyze,last_analyze,last_autovacuum,last_vacuum from pg_stat_user_tables order by n_live_tup desc limit4;

  -[ RECORD 1 ]----+------------------------------
  relname          | ps_rf_inst_prod
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-04 09:00:16.585295+02
  last_analyze     | 2017-12-05 16:08:31.218621+02
  last_autovacuum  | 
  last_vacuum      | 
  -[ RECORD 2 ]----+------------------------------
  relname          | man_x5
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-05 06:02:07.189184+02
  last_analyze     | 2017-12-05 16:12:58.130519+02
  last_autovacuum  | 
  last_vacuum      | 
  -[ RECORD 3 ]----+------------------------------
  relname          | tc_fint_x5
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-05 06:04:06.698422+02
  last_analyze     | 
  last_autovacuum  | 
  last_vacuum      | 
  -[ RECORD 4 ]----+------------------------------
  relname          | nap_inter_x5
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-04 08:54:16.764392+02
  last_analyze     | 2017-12-05 16:10:23.411266+02
  last_autovacuum  | 
  last_vacuum      | 

2小时前，我在所有5张最上面的桌子上运行真空吸尘器，但它并没有释放出很多空间

在这个数据库上，唯一发生的操作是truncate、insert和select。那么，我的一些桌子上怎么会有死元组呢？如果我只运行truncate、select，则不应创建插入查询元组

---

还有一个更大的问题，丢失的180G在哪里？

只是想提一下，解决方案是将带有pg_dump的数据库转储到一个文件中，删除数据库，然后恢复它。我在数据库的目录中有一些表示不再存在的对象的文件

你已经排除了TOAST和索引空间，是吗？pg_total_大小包括索引和TOAST如果

pg_total_relation_size（）

没有加起来，你可以试着从另一端接近它，也就是说，试着将

data/base/16400/

中的每个文件绑定到一个表中，看看是否有任何东西未解释<代码>选择oid:：regclass，pg_类中的pg_关系_文件路径（oid）将有所帮助（尽管这只报告主分叉的第一段，因此对于

/base/16400/123

，您还需要计算

123.1

，

123.2

，

123_fsm

，等等）。存储布局已记录在案。目录/base/16400/xxx中的文件假定是表的relfilenode，对吗？当我运行'select relname，relfilenode，oid from pg_class where relfilenode='xxx'时，我想找到文件表示的对象，对吗？问题是这个查询的结果是空的……你知道吗？有人吗？

[/data/base] : du -sk * | sort -n
7284    13322
7868    13323
7892    1
8156    166694
298713364       16400

combit=>select relname,n_dead_tup,last_autoanalyze,last_analyze,last_autovacuum,last_vacuum from pg_stat_user_tables order by n_live_tup desc limit4;

  -[ RECORD 1 ]----+------------------------------
  relname          | ps_rf_inst_prod
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-04 09:00:16.585295+02
  last_analyze     | 2017-12-05 16:08:31.218621+02
  last_autovacuum  | 
  last_vacuum      | 
  -[ RECORD 2 ]----+------------------------------
  relname          | man_x5
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-05 06:02:07.189184+02
  last_analyze     | 2017-12-05 16:12:58.130519+02
  last_autovacuum  | 
  last_vacuum      | 
  -[ RECORD 3 ]----+------------------------------
  relname          | tc_fint_x5
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-05 06:04:06.698422+02
  last_analyze     | 
  last_autovacuum  | 
  last_vacuum      | 
  -[ RECORD 4 ]----+------------------------------
  relname          | nap_inter_x5
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-04 08:54:16.764392+02
  last_analyze     | 2017-12-05 16:10:23.411266+02
  last_autovacuum  | 
  last_vacuum      |