我在mac osx上使用postgres 9.3运行,并且我有一个失去控制的数据库。我以前有一个表有一个存储大数据的列。然后我注意到,由于pg_toast表,db大小增长到大约19gb。然后我删除提到的列并运行vacuum以便再次将db调整到更小的大小,但它保持不变。那么如何缩小数据库大小呢?
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 20;
结果
pg_toast.pg_toast_700305 | 18 GB
pg_toast.pg_toast_700305_index | 206 MB
public.catalog_hotelde_images | 122 MB
public.routes | 120 MB
VACUUM VERBOSE ANALYZE pg_toast.pg_toast_700305; INFO: vacuuming "pg_toast.pg_toast_700305"
INFO: index "pg_toast_700305_index" now contains 9601330 row versions in 26329 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.06s/0.02u sec elapsed 0.33 sec.
INFO: "pg_toast_700305": found 0 removable, 0 nonremovable row versions in 0 out of 2393157 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.06s/0.07u sec elapsed 0.37 sec.
VACUUM
路线表的结构
id serial NOT NULL,
origin_id integer,
destination_id integer,
total_time integer,
total_distance integer,
speed_id integer,
uid bigint,
created_at timestamp without time zone,
updated_at timestamp without time zone,
CONSTRAINT routes_pkey PRIMARY KEY (id)
答案 0 :(得分:5)
尝试以下方法:
vacuum full
答案 1 :(得分:5)
您可以使用以下两种类型的吸尘之一:标准或完整。
标准
VACUUM table_name;
全:
VACUUM FULL table_name;
请记住,VACUUM FULL锁定它正在处理的表格,直到它完成。
您可能希望在频繁上传/删除活动的桌面上更频繁地执行标准真空,它可能不会给您提供与vacuum full一样多的空间,但您可以运行SELECT,INSERT,UPDATE等操作。删除,完成时间会更短。
在我的情况下,当pg_toast(以及其他表格)失控时,标准的VACUUM略有不同,但还不够。我使用VACUUM FULL来回收更多的磁盘空间,这对于大型关系来说非常慢。我决定tune autovacuum并在我经常更新的桌子上更频繁地使用标准VACUUM。
如果您需要使用VACUUM FULL,则应在用户不太活跃时执行此操作。 另外,请勿关闭autovacuum。
您可以通过在命令中添加 verbose 来获取更多信息:
VACUUM FULL VERBOSE table_name;