PK的顺序索引的填充因子

一尘不染

PK的顺序索引的填充因子

sql

是的，再次填充因子。我花了很多时间阅读，但我无法确定每种情况下哪个填充因子更好。问题是我不了解何时以及如何进行碎片化。我正在将数据库从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序列的类似结构索引将每2个月以大约50.000个寄存器的块（一次写入）写入，读数为10-50 /分钟。

50％的填充因子意味着在每个插入中将生成一个新页面并将50％的现有记录传输到一个新的生成页面吗？

50％的填充系数意味着在创建新页面时将保留复制的记录，以避免在两者之间插入？

仅当没有空间分配插入的记录时才生成新页面吗？

如您所见，我很困惑。我希望得到一些帮助-也许是阅读PostgreSQL和索引填充因子的好链接。

阅读 141

2021-03-17

共1个答案

一尘不染

[`FILLFACTOR`](http://www.postgresql.org/docs/current/interactive/sql-

createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS)

只有INSERT并且SELECT您应该FILLFACTOR在100任何地方都使用a 。

如果您不打算用UPDATEs来“摆动”，那么在每个内存块上留出摆动的空间是没有意义的。

背后的机制FILLFACTOR非常简单。INSERT只能将每个数据页（通常为8
kb的块）填充到FILLFACTOR设置所声明的百分比。此外，无论何时跑步VACUUM FULL或CLUSTER在桌子上，每个块都将重新建立相同的摆动空间。理想情况下，这允许UPDATEs将新的行版本存储在同一数据页中，这在处理大量UPDATEs时可以显着提高性能。与
HOT更新 结合使用也有好处

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

基本信息来源：CREATE TABLE或上的手册CREATE 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位图。
如果定义和，则所有列均为，并且完全使用了NULL位图，从而释放了8个字节。
如果不声明列的话，这甚至对每行有效。如果所有列都有值，则此行没有NULL位图。在你的情况，这导致了矛盾的效果，在值填充的和可以让你的存储大小小
或至少保持不变： *
et_mode``token NOT NULL``NOT NULL
NOT NULL``et_mode``token

基本信息源：有关数据库物理存储的手册。

将行的大小（用值填充）与原始表进行比较，以获得明确的证明：

SELECT pg_column_size(t) FROM dev_transactions t;

2021-03-17