我有一个事务负载很重的数据库(每天大约插入2-3百万个事务),每个事务插入都会在提交事务之前创建几个临时表。
在这个过程中,pg_attribute表变得臃肿了,到目前为止,表中的行数还不到10 k,但大小仍然是10 GB。
我在这个表上运行了几次完全真空,但没有帮助。甚至重新启动了DB,并再次运行完全真空。
我有什么选择?
更新
postgres=# VACUUM (VERBOSE) pg_catalog.pg_attribute;
INFO: vacuuming "pg_catalog.pg_attribute"
INFO: "pg_attribute": found 0 removable, 25 nonremovable row versions in 1 out of 49 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 650634809
There were 30 unused item pointers.
Skipped 0 pages due to buffer pins, 25 frozen pages.
0 pages are entirely empty.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres=#
SELECT schemaname, relname, n_live_tup, n_dead_tup, last_autovacuum
FROM pg_stat_all_tables
ORDER BY n_dead_tup
/ (n_live_tup
* current_setting('autovacuum_vacuum_scale_factor')::float8
+ current_setting('autovacuum_vacuum_threshold')::float8)
DESC
LIMIT 10;
1条答案
按热度按时间0g0grzrc1#
有什么东西阻碍了元组。因为重启数据库并没有解决问题,所以它必须是持久的。据我所知,这要么是一个准备好的事务,要么是一个逻辑复制槽。所以请查看pg_prepared_xacts和pg_replication_slots视图。