**autovacuum_max_workers** : Avant la version 18, la modification du paramètre `autovacuum_max_workers` nécessitait le redémarrage de l'instance pour qu'elle soit prise en compte. C'était problématique pour les serveurs en 24/7 pour lesquels une augmentation de ce paramètre aurait permis de traiter plus de bases et de tables en même temps. En version 18, le changement de ce paramètre ne nécessite plus qu'un rechargement de la configuration. Cependant, pour que PostgreSQL puisse allouer en mémoire partagée statique les structures nécessaires pour chaque worker potentiel, il a fallu définir une limite et c'est là que rentre en jeu le nouveau paramètre, `autovacuum_worker_slots`. Au démarrage, `autovacuum_worker_slots` est utilisé pour calculer la taille des structures nécessaires au fonctionnement de l'`autovacuum`. La valeur 16, par défaut, devrait suffire à la plupart des installations. Le paramètre `autovacuum_max_worker` a une valeur comprise entre 1 et `autovacuum_worker_slots` et est utilisé comme limite du nombre de workers pour l'`autovacuum`. **autovacuum_vacuum_max_threshold** : Une autre amélioration a été apportée en version 18. Pour éviter que le nombre cible de lignes mortes soit trop important, il est possible de configurer une limite haute. Un nouveau paramètre a été créé : `autovacuum_vacuum_max_threshold`. Si sa valeur est inférieure au résultat du calcul standard `autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor * nb_lignes_vivantes`, c'est lui qui est pris en compte pour la comparaison avec le nombre de lignes mortes. Ce nouveau paramètre permet de résoudre partiellement le problème des tables avec de très nombreuses lignes que l'autovacuum visite trop rarement, et qui accumulent une fragmentation importante. En effet, avec la valeur par défaut de `autovacuum_vacuum_threshold`, il faut attendre que 20 % des lignes soient modifiées pour que l'autovacuum se déclenche. Pour une table d'un milliard de lignes, il fallait donc attendre la modification de 200 millions d'entre elles. Il était alors (et il reste) conseillé de modifier `autovacuum_vacuum_threshold` et/ou `autovacuum_vacuum_scale_factor` sur les grandes tables, et/ou de mener des `VACUUM` la nuit ou le week-end. Avec sa valeur par défaut de 100 millions de lignes, `autovacuum_vacuum_max_threshold` modifie le comportement à partir de 500 millions de lignes (pour une table monolithique, hors autre paramétrage) et réduit le besoin d'administration. Le seuil peut être modifié globalement s'il est jugé trop haut, ou par table ainsi : ``` ALTER TABLE t1 SET (AUTOVACUUM_VACUUM_MAX_THRESHOLD = 10_000_000); ``` La valeur `-1` revient à l'ancien comportement. La [discussion](https://www.postgresql.org/message-id/956435f8-3b2f-47a6-8756-8c54ded61802%40dalibo.com) pointe les avantages et inconvénients de cet autovacuum plus agressif : mise à jour plus fréquente des statistiques sur les données récentes, _visibility map_ plus à jour, `VACUUM` insensible, temps perdu à parcourir de gros index de manière répétée… Attention : ce paramètre ne change le comportement du démon `autovacuum` que pour ce qui concerne la partie `VACUUM`. Le démon ne lancera pas plus souvent qu'avant des `ANALYZE` (les développeurs ne sont pas sûrs qu'un `ANALYZE` plus fréquent est toujours une bonne chose).