如何缩小pg_toast表?

dc1*_*c10 18 postgresql

我在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;
Run Code Online (Sandbox Code Playgroud)

结果是

 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
Run Code Online (Sandbox Code Playgroud)

路线表的结构

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)
Run Code Online (Sandbox Code Playgroud)

Joe*_*ove 7

请尝试以下方法:

vacuum full
Run Code Online (Sandbox Code Playgroud)

  • 威尔罗宾逊,危险!在生产系统上运行"VACUUM FULL"之前,请确保您了解[潜在后果](https://wiki.postgresql.org/wiki/VACUUM_FULL). (15认同)
  • @hakamadare"这个文件对于PostgreSQL 9.0及以上版本已经过时了.大部分内容仅适用于PostgreSQL 8.4及以下版本." (10认同)
  • 就是这样 !桌子被清理干净了。谢谢 (2认同)
  • @BenjaminToueg 真空完整作品或“真空完整表格名称”也有效。正如 linuxfreaks 提到的,重建表,删除旧表并将重建的表重命名回原始名称也有效。没有什么太花哨的了,vacuum full 命令基本上是“锁定”表,然后对其进行“碎片整理”(简化)。重建是“刷新所有数据”,速度更快,但它在生产系统上也存在问题,因为您的 OLD 表数据可能会在此过程中被修改。如果系统出现故障,无论哪种方式都可以正常工作。 (2认同)

Bat*_*Cat 7

您可以使用两种类型的吸尘中的一种:标准吸尘或完全吸尘。

标准:

VACUUM table_name;
Run Code Online (Sandbox Code Playgroud)

充分:

VACUUM FULL table_name; 
Run Code Online (Sandbox Code Playgroud)

请记住,VACUUM FULL会锁定正在处理的桌子,直到完成为止。

您可能希望在具有频繁上载/删除活动的表上更频繁地执行标准真空,它可能没有真空完全那样大的空间,但是您将能够运行SELECT,INSERT,UPDATE和DELETE之类的操作将花费更少的时间来完成。

在我的情况下,当pg_toast(以及其他表)失控时,标准VACUUM略有不同,但还不够。我使用VACUUM FULL来回收更多的磁盘空间,这在大型关系中非常慢。我决定调整自动真空度并在经常更新的表上更频繁地使用标准VACUUM。

如果需要使用VACUUM FULL,则应在用户不活跃时使用它。另外,请勿关闭自动真空。

您可以通过在命令中添加详细信息来获得一些其他信息:

VACUUM FULL VERBOSE table_name;
Run Code Online (Sandbox Code Playgroud)