让我们创建一个临时表(我选择临时表,因为 autovacuum 不会为这种表运行):
CREATE TEMP TABLE test (
id int PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
value int
);
INSERT INTO test (value) SELECT 0 FROM generate_series(0, 250);
SELECT ctid, * FROM test;
我们将看到该表由两页组成:
(0,1) 1 0
(0,2) 2 0
...
(0,226) 226 0
(1,1) 227 0
...
(1,25) 251 0
现在如果我们更新一行
UPDATE test SET value = -1 WHERE id = 1;
SELECT ctid, * FROM test WHERE value <> 0;
我们将看到新的行版本被插入到表的末尾(在第二页,它有足够的可用空间进行此操作),这是标准的 PostgreSQL 行为(来自 (0,1) 的旧行版本是标记为死亡)
(1,26) 1 -1
让我们检查页面的可用空间:
CREATE EXTENSION pg_freespacemap;
SELECT * FROM pg_freespace('test');
我们得到
0 0
1 0
即没有可用空间;文档说在真空运行后更新了可用空间图(FSM)。现在,如果我们从第一页更新另一行:
UPDATE test SET value = -1 WHERE id = 2;
SELECT ctid, * FROM test WHERE value <> 0;
我们会看到
(0,227) 2 -1
(1,26) 1 -1
新行版本并没有添加到第2页而是添加到当前页,因为我们在更新id为1的记录时腾出了空间。但是这种做法不符合我对FSM的理解。以下是我的问题:
pg_freespace('test')
如果返回零,PostgreSQL 如何在第二次更新时知道第一页中有可用空间?我认为这个函数为您提供了 FSM,而 FSM 又在 UPDATE 的情况下使用,以确定哪个页面有足够的可用空间来存储新的行版本。- 一般来说,我在想,即使第一行被标记为死,但它会在第一页占据一些空间,并且只有在真空之后才会释放这个空间。因此,我期望第二个 UPDATE 也会将新行版本添加到第二页。
这将包含一些 PostgreSQL 内部;对不起,你要求的。
Autovacuum 不会在临时表上运行(因为它们在您的会话之外是不可见的),并且无论如何,一两次更新都不会触发 autovacuum。现在是
VACUUM
创建和维护可用空间图,因此在您的情况下没有可用空间图。pg_freespacemap
不会出错,但会报告为 0。由于缺少可用空间图,PostgreSQL 必须查看各个块才能找到其中有可用空间的块。这就留下了为什么第二次更新可以找到空间在块 0 中创建元组的谜团。
为了回答这个谜题,让我们讨论一下你的陈述及其效果。
pageinspect
您可以使用扩展程序验证所有这些。第一个
UPDATE
:这将元组 (0,1) 标记为已更新(它设置
xmax
)并创建新的元组 (1,26),正如您所期望的那样。以下查询:
此查询可以在块 0 上获得页锁并执行堆修剪,即释放死元组占用的空间的“微真空”。请注意,它不能删除 (0,1),因为它仍然在索引中被引用,但是行指针(0,1) 变成了一个
LP_DEAD
不占用任何空间的“存根”标记。该死元组占用的空间被释放。注意,如果你不运行 that
SELECT
,下面UPDATE
会在块 0 上进行堆修剪,所以效果是一样的。第二个
UPDATE
:由于缺少空闲空间映射,该语句查看块 0 并注意到有足够的空闲空间,因此它执行HOT 更新并将新元组放入块 0。