在”PostgreSQL vacuum原理一功能与参数中我在致讲了vacuum的几大功能点，以及相关的一些参数，如何来调整vacuum。那么这一章节主要讲比较内核的一些东西。
1.PG发起vacuum的流程
在PG实例起动时，postmaster 进程会fork出autovacuum launcher进程。
完整的vacuum进程创建如下：
pg_ctl命令行起动PG实例，然后fork出postmaster Server进程，这也是PG的主进程。postmaster进程再负责fork各种其它后台进程。
按以下顺序，依次起动：logger进程，checkpoint进程，writer进程，wal writer进程，autovacuum launcher进程以及stats collector进程。
autovacuum launcher进程再负责fork autovacuum worker进程。我们具体的vacuum动作最后都交由worker进程来做，干杂活。
默认情况下，最多由三个worker进程，由参数autovacuum_max_workers控制。
2. autovacuum launcher进程
autovacuum launcher是vacuum worker的总调度者。在起vacuum worker时，会先balance一次vacuum_cost_limit值，balance的过程就是新的worker起来时，
赋予此worker后面因vacuum而消耗的最大允许IO limit。因为vacuum_cost_limit值是所有worker平摊的，我们设置的vacuum_cost_limit是所有worker的总累加值。
因此新的work加入进来后，需要做两件事：一是计算新的work的cost_limit值；二是调整已经在running的worker的cost_limit值。
另外值得注意的是：从目前源码中得知，vacuum_cost_limit的值是要被vacuum_cost_delay时间平分掉的。假设cost_limit的值是200，cost_delay是10毫秒，max worker是3个，
并且都在running状态。那么可以计算出，其实每个worker每个毫秒所能允许消耗的IO值是：200/10/3，约为6.6。
另外autovacuum launcher还要重建db list，根据autovacuum_naptime去计算每个db分配到的时间。参数介绍请见：”PostgreSQL vacuum原理一功能与参数”另外，
值得注意的是，虽然可以几个worker一起运行，但是目前的做法是，在db 级别并行。也就是说worker是根据autovacuum launcher重建的db list去逐一遍历每个DB的。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/30088583/viewspace-1601849/ ，如需转载，请注明出处，否则将追究法律责任。
