CREATE TABLE "fact_table" (
  "pk_a" bigint                 NOT NULL ENCODE lzo,"pk_b" bigint                 NOT NULL ENCODE delta,"d_1"  bigint                 NOT NULL ENCODE runlength,"d_2"  bigint                 NOT NULL ENCODE lzo,"d_3"  character varying(255) NOT NULL ENCODE lzo,"f_1"  bigint                 NOT NULL ENCODE bytedict,"f_2"  bigint                     NULL ENCODE delta32k
)
DISTSTYLE KEY
DISTKEY ( d_1 )
SORTKEY ( pk_a,pk_b );

该表以高基数维度分布.

该表按一对按时间顺序递增的字段排序.

该表包含超过20亿行,并使用~350GB的磁盘空间,均为“每个节点”.

我们的每小时管理包括更新一些最近的记录(在表的最后0.1％内,基于排序顺序)并插入另外的100k行.

无论我们选择何种机制,VACUUMing表都变得过于繁琐：
– 排序步骤需要几秒钟
– 合并步骤需要6个小时

我们可以从SELECT * FROM svv_vacuum_progress中看到;所有20亿行都被合并了.即使前99.9％完全不受影响.

我们的理解是合并只会影响：
1.删​​除记录
2.插入记录
3.从(1)或(2)到表格末尾的所有记录

我们尝试过DELETE和INSERT而不是UPDATE,现在DML步骤明显更快了.但是VACUUM仍然合并了所有20亿行.

DELETE FROM fact_table WHERE pk_a > X;
-- 42 seconds

INSERT INTO fact_table SELECT <blah> FROM <query> WHERE pk_a > X ORDER BY pk_a,pk_b;
-- 90 seconds

VACUUM fact_table;
-- 23645 seconds

实际上,VACUUM合并了所有20亿条记录,即使我们只是修剪了表格末尾的最后746行.

问题

有没有人对如何避免这种巨大的VACUUM开销有任何建议,并且只有MERGE在最后0.1％的表上？