小编BrM*_*M13的帖子

最近，我将 PostgreSQL 8.2.11 服务器升级到 8.4，以便利用 autovacuum 功能并与 30 左右的其他 PGSQL 服务器保持一致。这是由管理硬件的单独 IT 小组完成的，因此我们在任何其他升级上没有太多选择（暂时不会看到 9+）。服务器存在于一个非常封闭的环境中（隔离网络，有限的root权限），运行在RHEL5.5（i686）上。升级后，数据库以每天 5-6 GB 的速度不断增长。通常情况下，整个数据库大约为 20GB；目前，它是~89GB。我们还有其他几台服务器，它们运行等效的数据库，并通过第 3 方应用程序（我无法访问内部工作原理的应用程序）将记录相互同步。其他数据库应该是~20GB。

运行以下 SQL，很明显特定表存在问题，更具体地说，它的 TOAST 表存在问题。

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_16874 | 89GB  
  somes00.warmstates | 1095 MB  
  ...  
(20 行)

此 TOAST 表用于名为“timeseries”的表，该表保存大量斑点数据记录。SUM(LENGTH(blob)/1024./1024.)时间序列中所有记录的A为该列产生约 16GB。应该有什么理由 …