填充顺序索引为PK的因子

时间:2013-01-06 21:53:01

标签: sql postgresql

是的,再次填充因子。我花了很多时间阅读,我无法确定每个案例哪个是更好的填充因子。问题是我不明白何时以及如何进行碎片化。我正在将数据库从MS SQL Server迁移到PostgreSQL 9.2。

案例1)连续(连续)PK中10-50次插入/分钟,每小时读数20-50次。

CREATE TABLE dev_transactions
(
  transaction_id serial NOT NULL,
  transaction_type smallint NOT NULL,
  moment timestamp without time zone NOT NULL,
  gateway integer NOT NULL,
  device integer NOT NULL,
  controler smallint NOT NULL,
  token integer,
  et_mode character(1),
  status smallint NOT NULL,
  CONSTRAINT pk_dev_transactions PRIMARY KEY (transaction_id)
)
WITH (
  OIDS=FALSE
);

案例2)PK顺序的类似结构索引将以块(一次)写入~50,000个寄存器,每2个月,读数为10-50 /分钟。

50%的填充因子意味着每个插入内容都会生成一个新页面并将50%的现有记录传输到新的生成页面?

50%的填充因子意味着在创建新页面时,将保留复制的记录以避免插入之间的插入?

只有在没有空间分配记录时才会生成新页面?

你可以看到我很困惑;我会很感激它的一些帮助 - 也许是阅读PostgreSQL和索引填充因子的好链接。

1 个答案:

答案 0 :(得分:10)

FILLFACTOR

只有INSERTSELECT,您应该在任何地方使用FILLFACTOR 100

如果你不打算用UPDATE“摆动”,那么每个内存块的摆动空间是没有意义的。

FILLFACTOR背后的机制非常简单。 INSERT仅填充每个数据页(通常为8 kb块),最多为FILLFACTOR设置声明的百分比。此外,无论何时在桌面上运行VACUUM FULLCLUSTER,都会重新建立每个块的相同摆动空间。理想情况下,这允许UPDATE在同一数据页中存储新的行版本,这可以在处理大量UPDATE时提供显着的性能提升。与 H.O.T组合也是有益的。更新

如果没有更新,请不要为此浪费空间并设置FILLFACTOR = 100

基本信息来源:CREATE TABLECREATE INDEX上的手册。

其他优化

但是你可以做别的东西 - 因为你似乎是一个优化的吸盘...:)

CREATE TABLE dev_transactions
( transaction_id serial PRIMARY KEY,
  gateway integer NOT NULL,
  moment timestamp NOT NULL,
  transaction_type smallint NOT NULL,
  status smallint NOT NULL,
  device integer NOT NULL,
  controler smallint NOT NULL,
  token integer,
  et_mode character(1));

这可以针对数据对齐优化您的表格,并避免典型64位服务器的填充并节省几个字节,平均可能只有8个字节 - 通常不能用“列俄罗斯方块”挤出很多东西:

此外,请在表格开头保留NOT NULL列,以获得非常小的效果奖励。

此外,您的表格有 9列。这意味着扩展 NULL位图的额外 8字节 - 这将适用于 8列的初始1字节NULL位图。<登记/> 如果您定义et_modetoken NOT NULL,则所有列都为NOT NULL,并且根本使用NULL位图,释放8个字节。
如果您不声明列NOT NULL,则每行甚至可以工作。如果所有列都有值,则此行没有NULL位图。在您的情况下,这会导致悖论效应,即填充et_modetoken的值可以使您的存储空间更小或至少保持不变:

基本信息来源:the manual on Database Physical Storage

将行的大小(用值填充)与原始表进行比较,以获得明确的证明:

SELECT pg_column_size(t) FROM dev_transactions t;