PostgreSQL有一个可选但是被推荐的特性autovacuum（从8.1版本加入），它的目的是自动执行VACUUM和ANALYZE 命令,回收被表示为删除状态记录的空间。
对表元组的UPDATE或DELETE操作并未立即删除旧版本的数据,表中的旧元组只是被标识为删除状态,并未立即释放空间。
这种处理对于多版本并发控制（MVCC）是必要的,如果一个元组的版本仍有可能被其它事务看到,那么久不能删除元组的该版本。
当事务提交后,过期元组版本将对事务不再有效,因而其占据的空间必须回收以供其他新元组使用,以避免磁盘空间被消耗殆尽。
vacuum 不会清理重组空间,只会使元组空间被重用,表的末尾页面会被截断。
src/include/storage/itemid.h
typedef ItemIdData *ItemId;
/*
* lp_flags has these possible states. An UNUSED line pointer is available
* for immediate re-use, the other states are not.
*/
#define LP_UNUSED 0 未使用 /* unused (should always have lp_len=0) */
#define LP_NORMAL 1 已使用/* used (should always have lp_len>0) */
#define LP_REDIRECT 2 HOT重定向/* HOT redirect (should have lp_len=0) */
#define LP_DEAD 3 死元祖/* dead, may or may not have storage */
vacuum full 会重组,数据文件会被重建,relfilenode会变更。
-
-
更新被PostgreSQL查询规划器使用的数据统计信息。
-
-
保护老旧数据不会由于事务ID回卷或多事务ID回卷而丢失。
FREEZE 冻结，ANALYZE 分析更新统计信心，清理死元祖。
2.1 vacuum相关概念-Disk based FSM
用磁盘上的文件实现,替换共享内存固定大小的空闲空间映射(FSM)。
看到这个定义,当时就想起了main、VM、FSM这三种磁盘上的文件，按照上面的定义来说难道还有某个版本的PG中FSM文件不是存储在磁盘上的？赶紧上官网查了一下,恍然大悟ing... ...
原来8.3之前FSM可见空间映射文件是不存储在物理磁盘上的呀~
![]( "61d50e1bbd362.png")
FSM，指的是Free Space Map，空闲空间映射表。一个relation有多个8KB大小的block，这些block存储在磁盘上。一个relation最大只能有4G个block，每个block大小为8KB，也就是说一个relation的磁盘大小最大为32TB。
relation的不断的插入删除记录，会造成很多的block其实是有空闲空间的，Page的空闲空间管理的只是8KB空间内有多少剩余空间，而FSM管理的则是relation对应的所有的Block（或者说page，whatever，反正都是这8KB的空间）分别有多少剩余空间。
在数据库系统内部,这些文件（main、FSM、VM等）也被成为相应关系的分支（fork）；空闲空间映射是表/索引数据文件的第一个分支（分支编号为1），可见性映射文件是数据文件的第二个分支（分支编号为2）,数据文件的分支编号为0。
每个关系可能有4种分支,分支编号分别为0、1、2、3,0号分支main为关系数据文件的文件主体。1号分支fsm保存了main分支中空闲空间的信息，2号分支vm保存了main分支中可见性的信息,3号分支init是很少见的特殊分支，通常表示不背日志记录的表与索引。
vacuum过程是一种维护过程,它的两个主要任务是删除死元组,以及冻结事物标识,由于清理过程设计全表扫描,因此该过程代价高昂,在PG8.4版本中引入了可见性映射（VM）文件来提高移除死元组的效率,在PG9.6版本中增强了VM,从而改善了冻结的过程。
冻结的过程有两种模式,依特定条件而择其一执行。一种为惰性模式另一种为迫切模式。惰性模式下,冻结过程仅适用目标表对应的VM扫描包含死元组的页面。迫切模式会扫描所有的页面,无论其是否包含死元组,都会更新与冻结过程相关的系统视图,并在可能的情况下删除不必要的CLOG文件。
当元组被修改时,元组会复制出多个版本(MVCC),当事物提交后,历史的版本对其它事物不可见,被标记为死元祖,等待autovacuum清理。死元组的产生也是因为PostgreSQL中没有单独的回滚段,而是将历史版本直接记录在数据页面中。
2.5 vacuum相关概念- CLOG(XACT)
包含了事务的元数据。这种日志用于告诉PostgreSQL哪个事务已经完成、哪个还没有完成。clog是比较小的并且没有任何理由会膨胀，所以，你应该没有任何理由去碰触它。在任何时候你都不应该从pg_clog里删除文件，如果你这样子做，还不如完全地删除整个数据库目录。缺少clog是不可恢复的。
请注意，这意味着，如果你在$PGDATA目录里备份文件，你应该确定同时包含pg_clog和pg_xlog，否则你可能会发现你的备份是不可用的。
从指定的表中依次处理每一张表。
获取表上的ShareUpdateExclusiveLock锁,此锁允许其他事物对该表进行读取。
扫描表中所有的页面，以获取所有的死元组,并在必要时冻结旧的元组。
删除指向相应死元组的索引元组。
对表的每个页面执行步骤6和7中的操作。
删除死元组,并重新分配页面中的活元组。
更新目标表对应的FSM与VM。
如果最后一个页面没有任何元组,则截断最后一页。
更新与目标表清理过程相关的统计数据和系统视图。
更新与清理过程相关的统计数据和系统视图。
如果可能,移除CLOG中非必要的文件与页面。
1. Parallel vacuumdb jobs
vacuumdb工具支持一个jobs选项来定义运行VACUUM的数量。
vacuumdb [connection-option...] [option...] [ --table | -t table [( column [,...] )] ] ... [dbname]
vacuumdb [connection-option...] [option...] --all | -a
vacuumdb是用于清理一个PostgreSQL数据库的工具。vacuumdb也将产生由PostgreSQL查询优化器所使用的内部统计信息。
vacuumdb是 SQL 命令VACUUM的一个包装器。在通过这个工具和其他方法访问服务器来清理和分析数据库之间没有实质性的区别。
通过同时运行njobs 个命令来并行执行清理或者分析命令。这个选项会减少处理的时间， 但是它也会增加数据库服务器的负载。
vacuumdb将开启 njobs个到数据 库的连接，因此请确认你的max_connections 设置足够高以容纳所有的连接。
注意如果某些系统目录被并行处理，使用这种模式加上 -f（FULL）选项可能会导致死锁失败。
postgres@bogon-> vacuumdb -h 127.0.0.1 -p 5432 -F -f -z -v -j 3 -d postgres -U postgres
-j 3 并行度等于3
PostgreSQL13开始支持索引并行vacuum,VACUUM PARALLEL
VACUUM [ ( option [, ...] ) ] [ table_and_columns [, ...] ]
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ table_and_columns [, ...] ]
FULL [ boolean ]
FREEZE [ boolean ]
VERBOSE [ boolean ]
ANALYZE [ boolean ]
DISABLE_PAGE_SKIPPING [ boolean ]
SKIP_LOCKED [ boolean ]
INDEX_CLEANUP [ boolean ]
TRUNCATE [ boolean ]
PARALLEL integer PostgreSQL13 新增的 PARALLEL 参数
table_name [ ( column_name [, ...] ) ]
PostgreSQL12(含)及以前的版本，vacuum还是一个表一个表，一个索引一个索引的进行清理,PostgreSQL13 新增的 PARALLEL 参数。
使用integer后台处理器并行执行VACUUM 的索引真空和索引清理阶段。用于执行操作的处理器数量等于关系上支持并行清理的索引数量，该数量受PARALLEL 选项指定的工人数量的限制，如果有的话，该数量还受到max_parallel_maintenance_workers限制。
当且仅当索引的大小大于min_parallel_index_scan_size时，索引才能参与并行清理。
*请注意，不保证在执行期间会使用integer中指定的并行工作线程数。清理运行时可能需要比指定的更少的处理器，甚至根本没有处理器。每个索引只能使用一名处理器。
所以只有当表中至少有2索引时才会启动并行工作程序。在每个阶段开始之前启动清理工作进程，并在阶段结束时退出。这些行为可能会在未来的版本中发生变化。此选项不能与FULL选项一起使用。
目前仅限于索引，每个索引可以分配一个vacuum worker。
只有在至少有2个以上索引的表上使用parallel选项才有效。
初始化,VACUUM正在准备开始扫描堆。这个阶段应该很简短。
扫描堆, VACUUM正在扫描堆。如果需要，它将会对每个页面进行修建以及碎片整理，并且可能会执行冻结动作。heap_blks_scanned列可以用来监控扫描的进度。
清理索引,VACUUM当前正在清理索引。如果一个表拥有索引，那么每次清理时这个阶段会在堆扫描完成后至少发生一次。如果maintenance_work_mem不足以存放找到的死亡元组，则每次清理时会多次清理索引。
清理堆,VACUUM当前正在清理堆。清理堆与扫描堆不是同一个概念，清理堆发生在每一次清理索引的实例之后。如果heap_blks_scanned小于heap_blks_total，系统将在这个阶段完成之后回去扫描堆；否则，系统将在这个阶段完成后开始清理索引。
清除索引,VACUUM当前正在清除索引。这个阶段发生在堆被完全扫描并且对堆和索引的所有清理都已经完成以后。
截断堆,VACUUM正在截断堆，以便把关系尾部的空页面返还给操作系统。这个阶段发生在清除完索引之后。
执行最后的清除,VACUUM在执行最终的清除。在这个阶段中，VACUUM将清理空闲空间映射、更新pg_class中的统计信息并且将统计信息报告给统计收集器。当这个阶段完成时，VACUUM也就结束了。
2.Multiple autovacuum workers
allows the autovacuum daemon to operate on multiple tables concurrently.允许autovacuum守护进程同时对多个表进行操作。PostgreSQL8.3版本增强功能。
在“自动清理守护进程”实际上是由多个进程。有一个持久的守护进程，称为autovacuum启动程序，负责启动所有数据库的autovacuum工作进程。以上文字翻译自官方文档O(∩_∩)O守护进程who？autovacuum launcher
autovacuum launcher 进程可以理解为AutoVacuum机制的守护进程，周期性地调度autovacuum worker进程。
autovacuum launcher 进程在postgresql.conf文件中的相关配置参数（支持对每个表单独配置参数）如下：
track_counts：是否开启统计信息收集功能。
autovacuum：是否启动系统自动清理功能，默认值为on。
autovacuum_max_workers：设置系统自动清理工作进程的最大数量。
autovacuum_naptime：设置两次系统自动清理操作之间的间隔时间。
autovacuum_vacuum_cost_limit：声明将在自动VACUUM操作里使用的开销限制数值。
autovacuum_vacuum_cost_delay ：声明如果超过了上面的开销限制，则需要延迟清理的时间。
autovacuum_freeze_max_age：设置需要强制对数据库进行清理的XID上限值。
autovacuum_multixact_freeze_max_age：设置需要强制对数据库进行清理的multi XID上限值。因为AutoVacuum依赖于统计信息，所以只有track_counts=on 且 autovacuum=on 时，PostgreSQL才启动autovacuum launcher 进程。autovacuum launcher 进程会周期性地创建autovacuum worker 进程，最多能够创建autovacuum_max_workers个autovacuum worker 进程。
由于 MVCC 架构，PostgreSQL 在每次 UPDATE 和 DELETE 和inseert 回滚后 都会生成死元祖。
需要通过执行 VACUUM ANALYZE 命令来清理，该命令清理死元祖并更新相关的数据库统计信息。
还可以使用 VACUUM VERBOSE 在执行 VACUUM ANALYZE 时对数据页总数、可移动死元祖版本总数进行故障排除。
四、Vacuum "emergency mode"
当PostgreSQL 检测到XID回卷的可能性时，会主动清理。这由vacuum_failsafe_age和 vacuum_multixact_failsafe_age配置参数控制。
指定表的pg_class. relminmxid字段可以在VACUUM采取特殊措施避免系统范围内的 multixact ID 环绕失败之前达到。这是VACUUM最后的策略。.故障安全通常在防止事务 ID 环绕的自动清理已经运行一段时间时触发，尽管故障安全可能在任何VACUUM.当故障保护被触发时，将不再应用任何有效的基于成本的延迟，并绕过进一步的非必要维护任务（例如索引清理）。
默认值为 16 亿多条。尽管用户可以将此值设置为 0 到 21 亿之间的任何值，但VACUUM会默默地将有效值调整为不低于autovacuum_multixact_freeze_max_age 的105% 。
指定表的pg_class. relfrozenxid字段可以达到之前VACUUM采取非常措施避免系统范围的事务 ID 环绕失败。这是VACUUM最后的策略。故障安全通常在防止事务 ID 环绕的自动清理已经运行一段时间时触发，尽管故障安全可能在任何VACUUM.当故障保护被触发时，将不再应用任何有效的基于成本的延迟，并绕过进一步的非必要维护任务（例如索引清理）。
默认为 16 亿事物。尽管用户可以将此值设置为 0 到 21 亿之间的任意值，但VACUUM会默默地将有效值调整为不低于autovacuum_freeze_max_age 的105% 。跳过vacuum index, 不受delay限制等 防止 xid 回卷。PG 14的vacuum加速针对的是紧急情况, 即防止xid wraparound。
统计信息主要记录的就是表的行数页面以及不同列不同值的分布关系。表和索引的行数、页面数记录在系统表pg_class中，不同列不同值的分布关系在pg_statistic中。PgStat子进程是专门的统计信息收集器进程。
ANALYZE命令可以收集的统计信息，ANALYZE命令可以作为VACUUM的一个可选步骤。可以由autovacuum后台进程触发一次统计信息的更新操作。可以手工通过ANALYZE命令收集统计信息在某个表上，甚至某个列上。最好规划一个数据库范围内的ANALYZE，然后每天在系统不太繁忙的时候运行一次。
自动收集统计信息是依赖AUTOVACUUM定时触发analyze：
触发vacuum analyze的条件,表上(insert,update,delte 记录) >=autovacuum_analyze_scale_factor* reltuples(表上记录数) + autovacuum_analyze_threshold
手动收集统计信息的命令是analyze命令，analyze的语法格式：
analyze [verbose] [table[(column[,..])]]
verbose：显示处理的进度，以及表的一些统计信息
table：要分析的表名，如果不指定，则对整个数据库中的所有表作分析
column：要分析的特定字段的名字默认是分析所有字段
analyze 命令 会在表上加读锁
统计信息记录在哪里
用于进行查询计划选择的统计信息记录在系统表内
pg_statistic 记录值的分布率
pg_class 记录行数和页面数
统计信息是有autovacuum进程更新，PG使用MVCC机制进行数据库的并发控制，因此同样需要一组后台进程进行过期版本的清理。
autovacuum进程不止负责对过期元组进行清理，同时也负责定期更新表的统计信息。
PG的MVCC机制数据和数据的旧版本是统一存放在表文件上的，在清理时要进行全表扫描的操作，而统计信息的收集也是需要读取表文件的，这两个操作放在一起做可以在一定程度上节省IO；
清理废旧元组和更新统计信息都是通过收集表的元组变更数据来触发的，共享一套机制，因此放在一起处理也比较方便；
统计信息有两种触发方式：用户使用analyze命令手动触发(analyze/vacuum analyze)
在PG中，事务提交/回滚时会发消息给进程pgstat，pgstat会汇总这份信息并记录到文件中，autovacuum launcher会定期读取文件，获得，当某个表的改动超过阈值时便会触发一次统计信息的更新操作。
需要注意的是autovacuum worker也会给pgstat发消息，但实际上这个消息是通知pgstat统计更新/清理已经完成，可以清理统计信息了。因此stat file只有pgstat更新，launcher只是读取，不涉及并发写冲突。
stats collector process 源码路径 ："src/backend/postmaster/pgstat.c"
统计信息的存放地启动时, 读入已存在的统计文件, 或初始化0. 数据库运行过程中存储在内存和temp文件 postgresql.conf ->stats_temp_directory , 推荐配置在高速磁盘或内存文件系统中
正常关闭时会把统计信息从tmp目录拷贝到$PGDATA/pg_stat目录中，确保统计信息不会丢失。
每当死亡元组（dead tuple）超过以下公式时，就会触发自动清理
autovacuum_vacuum_threshold + pg_class.reltuples *
autovacuum_vacuum_scale_factor
死亡元组数可以认为是pg_stat_all_tables中n_dead_tup的值
由以上公式可以看出，一般在dead tuple达到20%时，会进行自动清理，50行的阈值是为了防止非常频繁地清理微小的表。
这个默认的比例比较适用于中小表，但如果表较大时，比如10GB大小的表，dead tuple达到2GB时才清理，这在清理的过程中会严重影响性能，一般来说解决方案有两种：
一是调小大表的比例因子
二是放弃比例因子，调大阈值
要注意在postgresql.conf中修改这些参数会产生全局影响，尤其调大阈值或调小比例因子会影响小表的清理，不过综合全局来看，可以忽略一些小表的清理问题。
在postgresql.conf中忽略比例因子,设置较大的阈值(例如设置autovacuum_vacuum_scale_factor = 0和autovacuum_vacuum_threshold = 10000),然后根据各个表的delete和update频繁程度以及表的数据量单独为每个表设置阈值：ALTER TABLE test SET (autovacuum_vacuum_threshold = 100);
autovacuum的清理过程是从数据文件中读取页面（默认8kB数据块），并检查它是否需要清理，如果没有死亡元组，页面就会被丢弃而不做任何更改，否则它被清理（死元组被删除）,被标记为“脏页”并最终写出来。成本核算基于postgresql.conf定义三个参数：
vacuum_cost_page_hit = 1 #如果页面是从shared_buffers读取的，则计为1。
vacuum_cost_page_miss = 10 #如果在shared_buffers找不到并且需要从操作系统中读取，则计为10(它 可能仍然从RAM提供,但我们不知道)
vacuum_cost_page_dirty = 20 #当清理修改一个之前干净的块时需要花费的估计代价，它表示再次把脏块刷 出到磁盘所需要的额外I/O,默认值为20
autovacuum_vacuum_cost_delay = 20ms #每次完成清理后睡眠20ms
autovacuum_vacuum_cost_limit = 200 #完成一次清理的消耗限制
比如：延迟20ms，则每秒可以清理50轮，乘以200后，即为10000的成本，那么：
shared_buffers读取是 10000/1*8KB = 80MB/s
os中读取是 10000/10*8KB = 8MB/s
vacuum写入是 10000/20*8KB = 4MB/s
可以根据硬件的配置，以及autovacuum主要是顺序读写的情况增加autovacuum_vacuum_cost_limit参数，比如增加到1000或2000，这会使吞吐量增加5倍或10倍。当然可以调整其他参数（每页操作成本，睡眠延迟），一般来说这几个参数默认足够，如果有明显autocuum问题时，再酌情修改。
当update,delete的tuples数量超过 autovacuum_vacuum_scale_factor * table_size + autovacuum_vacuum_threshold
指定表上事务的最大年龄配置参数autovacuum_freeze_max_age，默认为2亿，达到这个阀值将触发 autovacuum进程，从而避免 wraparound。
每个表dead tuples的数量（包括用户表和系统表）
pg_stat_all_tables.n_dead_tup
# dead/live tuples在每个表中的比率
(n_dead_tup / n_live_tup)
(pg_class.relpages / pg_class.reltuples)
Autovacuum一个相当好的特色是限流。清理是在后台运行的维护任务，对用户查询的影响最小。换句话说，它不应该消耗太多的资源(CPU和磁盘I/O)，这正是限流内置到autovacuum中的目的。
清理过程相当简单，它从数据文件中读取页面(8kB的数据块)，并检查是否需要清理。如果没有dead tuples，页面将被简单地丢弃，而不进行任何更改。
否则，它将被清理(删除dead tuples)，被标记为“脏的”，并最终被写出来。成本计算是基于以下三个基本操作的成本定义的:
vacuum_cost_page_miss = 10
vacuum_cost_page_dirty = 20
也就是说，如果从shared_buffers读取页面，则计数为1。如果shared_buffers中没有找到它而需要从操作系统中读取，计数为10(它可能仍然由RAM提供，但我们不知道)。最后，如果页面被清理弄脏了，则计数为20。这让我们可以计算autovacuum的“工作成本”。
通过限制一次性完成的工作量(默认设置为200)来实现限流，每次清理工作完成这么多工作(计数达到autovacuum_vacuum_cost_limit )，它就会休眠20毫秒:
autovacuum_vacuum_cost_delay = 20ms
autovacuum_vacuum_cost_limit = 200
那么，实际上允许做多少工作呢?使用20ms延迟，清理工作每秒可以执行50轮，每轮200意味着每秒10000。这意味着:
每秒从share_buffer读80M（假设不脏）。
每秒写4M（被autovacuum进程弄脏的页）。
考虑到当前硬件的能力，读/写大多是连续的，这些限制太低了。
我们通常做的是将cost_limit参数增加到1000(或2000)，这将使吞吐量增加5倍(或10倍)。当然，也可以调整其他参数(每页操作的成本、睡眠延迟)，但是我们很少这样做——更改成本限制就足够了。
autovacuum是在后台运行的维护任务,对用户查询的影响较小,换句话说,它不消耗太多资源(CPU和I/O),这正是autovacuum Throttling.
清理过程相当简单,它从数据文件中读取页面(默认8kB数据块),并检查它是否需要清理.如果没有死元组,页面就会被丢弃而不做任何更改.否则它被清理(死元组被删除),被标记为"脏"并最终写出来。
postgres=# create table test(id int,info text);
CREATE TABLE
postgres=# insert into test select generate_series(1,1000000),md5(random()::text);
INSERT 0 1000000
postgres=# create index idx_test on test(id);
CREATE INDEX
postgres=# create index idx_test_info on test(info);
CREATE INDEX
postgres=# vacuum (parallel 4) test;
VACUUM
Time: 64.417 ms
postgres=# vacuum (verbose true) test;
INFO: vacuuming "public.test"
INFO: launched 1 parallel vacuum worker for index cleanup (planned: 1)
INFO: "test": found 0 removable, 40 nonremovable row versions in 1 out of 8334 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 491
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.00 s, system: 0.03 s, elapsed: 0.04 s.
INFO: vacuuming "pg_toast.pg_toast_16384"
INFO: "pg_toast_16384": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 491
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
postgres=# \timing on
Timing is on.
postgres=# vacuum test;
VACUUM
Time: 6388.633 ms (00:06.389)
postgres=#
postgres@bogon-> vacuumdb -h 127.0.0.1 -p 5432 -F -f -z -v -j 3 -d postgres -U postgres
-j 3 并行度等于3
[root@bogon ~]# ps -ef |grep postgres
postgres 6438 46335 0 22:59 pts/1 00:00:00 vacuumdb -h 127.0.0.1 -p 5432 -F -f -z -v -j 3 -d postgres -U postgres
postgres 6442 86102 99 22:59 ? 00:00:01 postgres: postgres postgres 127.0.0.1(41236) VACUUM
postgres 6443 86102 37 22:59 ? 00:00:00 postgres: postgres postgres 127.0.0.1(41238) VACUUM
postgres 6444 86102 39 22:59 ? 00:00:00 postgres: postgres postgres 127.0.0.1(41240) VACUUM
postgres 6446 86102 0 22:59 ? 00:00:00 postgres: parallel worker for PID 6442
postgres 86102 1 0 08:21 ? 00:00:01 /opt/pgsql12/bin/postgres
postgres 86103 86102 0 08:21 ? 00:00:00 postgres: logger
postgres 86105 86102 0 08:21 ? 00:00:00 postgres: checkpointer
postgres 86106 86102 0 08:21 ? 00:00:15 postgres: background writer
postgres 86107 86102 0 08:21 ? 00:00:24 postgres: walwriter
postgres 86108 86102 0 08:21 ? 00:00:00 postgres: autovacuum launcher
postgres 86109 86102 0 08:21 ? 00:00:01 postgres: stats collector
postgres 86110 86102 0 08:21 ? 00:00:00 postgres: logical replication launcher
postgres 86113 86102 0 08:21 ? 00:00:12 postgres: postgres postgres [local] idle
执行了3个vacuum
postgres 6442 86102 99 22:59 ? 00:00:01 postgres: postgres postgres 127.0.0.1(41236) VACUUM
postgres 6443 86102 37 22:59 ? 00:00:00 postgres: postgres postgres 127.0.0.1(41238) VACUUM
postgres 6444 86102 39 22:59 ? 00:00:00 postgres: postgres postgres 127.0.0.1(41240) VACUUM
实验基于PostgreSQL13.3,在插入数据时可自动触发autovacumm,从而可以生成表的vm文件而无需手工触发vacumm,vm文件可以加快VACUUM清理的速度。
postgres=# create table test3(id int);
CREATE TABLE
insert into test4 select id from generate_series(1,1250) t(id);
INSERT 0 1250
postgres=# select pg_relation_filepath('test4');
pg_relation_filepath
----------------------
base/13580/17284
(1 row)
控制插入数据触发autovacuum的的阈值,默认值为1000
postgres=# show autovacuum_vacuum_insert_threshold;
autovacuum_vacuum_insert_threshold
------------------------------------
1000
(1 row)
控制插入数据时超过什么比例会触发autovacuum,默认值为20%
postgres=# show autovacuum_vacuum_insert_scale_factor;
autovacuum_vacuum_insert_scale_factor
---------------------------------------
0.2
(1 row)
postgres@bogon-> ll 17284*
-rw------- 1 postgres postgres 48K Jul 7 20:41 17284
-rw------- 1 postgres postgres 24K Jul 7 20:41 17284_fsm
-rw------- 1 postgres postgres 8.0K Jul 7 20:41 17284_vm
postgres=# CREATE TABLE test
postgres-# (
postgres(# id SERIAL
postgres(# ,tdate TIMESTAMPTZ
postgres(# ,name varchar(50)
postgres(# );
CREATE TABLE
INSERT INTO test
(tdate, name)
SELECT x, 'cuipeng'
FROM generate_series('2021-01-01 00:00:00'::timestamptz, '2021-09-16 00:00:00'::timestamptz,'5 seconds'::interval) a(x);
INSERT 0 4457521
postgres=# SELECT pg_size_pretty(pg_total_relation_size('test'));
pg_size_pretty
----------------
222 MB
(1 row)
5.VACUUM VERBOSE 获取数据页和死元祖相关信息
postgres=# VACUUM VERBOSE test;
INFO: vacuuming "public.test"
INFO: "test": found 0 removable, 134 nonremovable row versions in 1 out of 28392 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 528
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres=# DELETE FROM test WHERE tdate BETWEEN '2021-01-01' AND '2021-02-01';
DELETE 535681
postgres=# VACUUM VERBOSE ANALYZE test;
INFO: vacuuming "public.test"
INFO: "test": removed 535681 row versions in 3412 pages
INFO: "test": found 535681 removable, 137 nonremovable row versions in 3413 out of 28392 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 530
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 0 frozen pages.
0 pages are entirely empty.
CPU: user: 0.02 s, system: 0.01 s, elapsed: 0.63 s.
INFO: analyzing "public.test"
INFO: "test": scanned 28392 of 28392 pages, containing 3921840 live rows and 0 dead rows; 30000 rows in sample, 3921840 estimated total rows
VACUUM
INFO: "test": removed 535681 row versions in 3412 pages
found 535681 removable 535681可移动行
versions in 3412 pages 总3412页面
VACUUM VERBOSE 重新搜集信息 重新执行一次
postgres=# VACUUM VERBOSE ANALYZE test;
INFO: vacuuming "public.test"
INFO: "test": found 0 removable, 134 nonremovable row versions in 1 out of 28392 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 532
There were 0 unused item identifiers.
Skipped 0 pages due to buffer pins, 3411 frozen pages.
0 pages are entirely empty.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO: analyzing "public.test"
INFO: "test": scanned 28392 of 28392 pages, containing 3921840 live rows and 0 dead rows; 30000 rows in sample, 3921840 estimated total rows
VACUUM
