gpt4 book ai didi

postgresql - 在 Postgres 中加速 autovacuum

转载 作者:行者123 更新时间:2023-12-04 03:30:40 26 4
gpt4 key购买 nike

我有一个关于 Postgres 自动真空/真空设置的问题。
我有一个包含 45 亿行的表,有一段时间进行了大量更新,导致大约 15 亿个死元组。此时 autovacuum 需要很长时间(几天)才能完成。
在查看 pg_stat_progress_vacuum View 时,我注意到:

max_dead_tuples = 178956970
导致多次索引重新扫描(index_vacuum_count)
根据 docs - max_dead_tuples 是我们可以在需要执行索引真空循环之前存储的死元组数量,基于维护工作内存。
根据 this一个死元组需要 6 个字节的空间。
所以 6B x 178956970 = ~1GB
但我的设置是
maintenance_work_mem = 20GB
autovacuum_work_mem = -1
那么我错过了什么?为什么我的所有 1.5b 死元组都不能放入 max_dead_tuples 中,因为 20GB 应该提供足够的空间,为什么需要多次运行?

最佳答案

对于一个 VACUUM 中的死元组数量,硬编码限制为 1GB。循环,见 the source :

/*
* Return the maximum number of dead tuples we can record.
*/
static long
compute_max_dead_tuples(BlockNumber relblocks, bool useindex)
{
long maxtuples;
int vac_work_mem = IsAutoVacuumWorkerProcess() &&
autovacuum_work_mem != -1 ?
autovacuum_work_mem : maintenance_work_mem;

if (useindex)
{
maxtuples = MAXDEADTUPLES(vac_work_mem * 1024L);
maxtuples = Min(maxtuples, INT_MAX);
maxtuples = Min(maxtuples, MAXDEADTUPLES(MaxAllocSize));

/* curious coding here to ensure the multiplication can't overflow */
if ((BlockNumber) (maxtuples / LAZY_ALLOC_TUPLES) > relblocks)
maxtuples = relblocks * LAZY_ALLOC_TUPLES;

/* stay sane if small maintenance_work_mem */
maxtuples = Max(maxtuples, MaxHeapTuplesPerPage);
}
else
maxtuples = MaxHeapTuplesPerPage;

return maxtuples;
}
MaxAllocSizesrc/include/utils/memutils.h 中定义作为
#define MaxAllocSize   ((Size) 0x3fffffff) /* 1 gigabyte - 1 */
您可以游说 pgsql-hackers 列表以增加限制。

关于postgresql - 在 Postgres 中加速 autovacuum,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/66909708/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com