我有一个巨大的表，我无法删除行，只能更新存储大量 base64 数据的列，我应该将其更新为 null 以尝试释放空间。
所以我编写了一个脚本，它能够在 base64 中设置所有图像，期望在 Vacuum 之后释放空间！
图像设置为 null，执行真空，但表仍然具有完全相同的大小，我很确定必须立即释放空间，所以我做错了什么？
真空完全能够从我更新为空的巨大 varchar 数据中释放空间吗？（因为如果我要这样做，我需要锁定桌子，我需要确定）
转储大小减少了 10 倍，因此我预计数据库大小会有类似的行为。
这里的官方文档对我来说似乎很神秘。https://www.postgresql.org/docs/13/routine-vacuuming.html#AUTOVACUUM
有人可以解释一下在自动真空或手动触发真空期间发生了什么吗？
我犯了一个小错误，我的 VACUUM FULL 最终填满了实例的磁盘。我设法释放了足够的空间来重新启动 postgres，但恐怕不足以运行 VACUUM FULL 完成。
有没有办法释放失败的 VACUUM FULL 运行使用的空间？
PS：这是我使用的选项VACUUM (FULL, VERBOSE, ANALYZE, INDEX_CLEANUP)
我最近有几个数据库需要维护。我刚刚提出这个“防止事务 ID 环绕失败”。我检查了我的数据库并得到了数字：
我在这个数据库上做了vacuumdb -a -v，然后得到了数字：
在我看来还不够好？我应该担心吗？
如果我对 PostgreSQL 手册的理解正确，我应该使用真空冻结将计数器重置为零吗？我知道这个数据库会稳定增长，通常是在插入时，而不是在删除/更新时。
谢谢你。
有时我发现很难理解 postgreSQL 文档。
现在，VACCUM 部分（https://www.postgresql.org/docs/10/sql-vacuum.html）说这句话“在重写表时总是执行积极的冻结”。
这句话是否意味着 VACUUM FREEZE 与 FULL 一样？
在工作中，我们有一个用于排队作业的数据库表，因此它看到了很多吞吐量。我们遇到的一个问题是，在没有任何代码更改的周末之后，该表上的索引充满了死元组。当我们运行时VACUUM VERBOSE ANALYZE，这显示为“600461 死行版本还不能被删除，最旧的 xmin：902335252”（参见 [1]）。
当我们寻找阻止真空清除这些的原因时，它指向一个正在运行的查询LISTEN，使用 Postgres 的 pubsub 功能。这已经运行了好几天，我认为这是一种预期的使用方式LISTEN。
因此，解决这个问题的一种方法是确保我们的应用程序服务器定期重启，这样它们就不会监听这么长时间，或者让它们重启任何LISTEN运行时间超过某个时间段的服务器。也就是说，我想知道 Postgres 是否有一种简单的方法来处理这个问题。有没有办法配置事务以不阻止清理死元组？我们的应用程序代码中是否有问题导致 LISTEN 出现这种行为？
“不要有长时间运行的事务”作为一般原则对我来说是有意义的，但它是相当尴尬的，因为LISTEN它旨在用作获取流式更新的一种方式，所以我希望 Postgres 可能有一个很好的解决方案。
=> SELECT *
-> FROM pg_stat_activity
-> WHERE backend_xmin = '902335252';
-[ RECORD 1 ]----+------------------------------
datid | 16404
datname | company_web_backend
pid | 8936
leader_pid |
usesysid | 16388
usename | company_web_backend
application_name |
client_addr | 10.0.1.80
client_hostname |
client_port | 56654
backend_start | 2021-07-24 01:21:28.270245+00
xact_start | 2021-07-24 01:21:28.279008+00
query_start | 2021-07-24 01:21:28.279008+00
state_change | 2021-07-24 01:21:28.281313+00
wait_event_type | Client
wait_event | ClientWrite
state | idle
backend_xid |
backend_xmin | 902335252
query | LISTEN queued_jobs
backend_type | client backend
[1]
server=> VACUUM VERBOSE ANALYZE queued_jobs;
INFO: vacuuming "public.queued_jobs"
INFO: launched 2 parallel vacuum workers for index cleanup (planned: 2)
INFO: "queued_jobs": found 0 removable, 5324589 nonremovable row versions in 553064 out of 8685508 pages
DETAIL: 600461 dead row versions cannot be removed yet, oldest xmin: 902335252
There were 9061227 unused item identifiers.
Skipped 3 pages due to buffer pins, 5619824 frozen pages.
0 pages are entirely empty.
CPU: user: 1.42 s, system: 1.25 s, elapsed: 3.10 s.
INFO: vacuuming "pg_toast.pg_toast_37823"
INFO: "pg_toast_37823": found 0 removable, 414848 nonremovable row versions in 79545 out of 16530493 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 902335252
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 14394456 frozen pages.
0 pages are entirely empty.
CPU: user: 0.46 s, system: 0.12 s, elapsed: 0.58 s.
INFO: analyzing "public.queued_jobs"
INFO: "queued_jobs": scanned 30000 of 8685508 pages, containing 311159 live rows and 2103 dead rows; 30000 rows in sample, 90085799 estimated total rows
VACUUM
让我们创建一个临时表（我选择临时表，因为 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 的情况下使用，以确定哪个页面有足够的可用空间来存储新的行版本。
由于索引膨胀，我们正在经历许多放缓。在尝试优化索引时，重新创建它似乎会生成一个小得多的索引：
reviews_hotel_id_connection_id_review_date_created_at_review_id：原始索引
reviews_hotel_id_connection_id_review_date_created_at_new：原始索引的完全副本，重新创建
reviews | reviews_hotel_id_connection_id_review_date_created_at_review_id | 5296 kB
reviews | reviews_hotel_id_connection_id_review_date_created_at_new | 2944 kB
新索引的大小仅为原索引的 55%！
运行VACUUM ANALYSE reviews不会导致任何索引减少！
运行VACUUM FULL reviews使原始索引与新索引具有完全相同的大小：
reviews | reviews_hotel_id_connection_id_review_date_created_at_new | 2944 kB
reviews | reviews_hotel_id_connection_id_review_date_created_at_review_id | 2944 kB
尽管VACUUM FULL即使读取也会锁定表！是否可以在不导致停机的情况下优化索引？
有没有办法提前确定VACUUM FULL特定表上的磁盘空间将返回给操作系统？因此，您可以决定这样做是否值得。
如果有一个简单的查询可以为数据库/服务器中的每个表执行此操作（而不是单独执行每个表），则奖励。
我有一个 14.7 TB Postgres(9.1) 数据库，它必须长时间承受大量写入。我知道我需要密切管理我的事务 ID 以防止数据库锁定。最近我注意到查询速度变慢了，并且看到在我们的大型只读表上运行了多个自动清理，并带有“（防止回绕）”下标。我停止了正在运行的软件并执行了一个vacuumdb -F -a命令。但是，当我运行时，select current_query from pg_stat_activity我看到 autovacuum 进程仍在运行，即使在手动清理期间也是如此。我尝试杀死 autovacuumsselect pg_cancel_backend(pid)并且他们死了，但然后立即重新启动。我的问题：