From fa9dfe413c6ced9a3ed38cc2f295e5af737683d4 Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Wed, 12 Apr 2023 14:42:06 -0700 Subject: [PATCH v2 1/9] Make autovacuum docs into a sect1 of its own. This doesn't change any of the content itself. --- doc/src/sgml/maintenance.sgml | 332 +++++++++++++++++----------------- 1 file changed, 166 insertions(+), 166 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 9cf9d030a..a6295c399 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -59,6 +59,172 @@ pleasant and productive experience with the system. + + The Autovacuum Daemon + + + autovacuum + general information + + + PostgreSQL has an optional but highly + recommended feature called autovacuum, + whose purpose is to automate the execution of + VACUUM and ANALYZE commands. + When enabled, autovacuum checks for + tables that have had a large number of inserted, updated or deleted + tuples. These checks use the statistics collection facility; + therefore, autovacuum cannot be used unless is set to true. + In the default configuration, autovacuuming is enabled and the related + configuration parameters are appropriately set. + + + + The autovacuum daemon actually consists of multiple processes. + There is a persistent daemon process, called the + autovacuum launcher, which is in charge of starting + autovacuum worker processes for all databases. The + launcher will distribute the work across time, attempting to start one + worker within each database every + seconds. (Therefore, if the installation has N databases, + a new worker will be launched every + autovacuum_naptime/N seconds.) + A maximum of worker processes + are allowed to run at the same time. If there are more than + autovacuum_max_workers databases to be processed, + the next database will be processed as soon as the first worker finishes. + Each worker process will check each table within its database and + execute VACUUM and/or ANALYZE as needed. + can be set to monitor + autovacuum workers' activity. + + + + If several large tables all become eligible for vacuuming in a short + amount of time, all autovacuum workers might become occupied with + vacuuming those tables for a long period. This would result + in other tables and databases not being vacuumed until a worker becomes + available. There is no limit on how many workers might be in a + single database, but workers do try to avoid repeating work that has + already been done by other workers. Note that the number of running + workers does not count towards or + limits. + + + + Tables whose relfrozenxid value is more than + transactions old are always + vacuumed (this also applies to those tables whose freeze max age has + been modified via storage parameters; see below). Otherwise, if the + number of tuples obsoleted since the last + VACUUM exceeds the vacuum threshold, the + table is vacuumed. The vacuum threshold is defined as: + +vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples + + where the vacuum base threshold is + , + the vacuum scale factor is + , + and the number of tuples is + pg_class.reltuples. + + + + The table is also vacuumed if the number of tuples inserted since the last + vacuum has exceeded the defined insert threshold, which is defined as: + +vacuum insert threshold = vacuum base insert threshold + vacuum insert scale factor * number of tuples + + where the vacuum insert base threshold is + , + and vacuum insert scale factor is + . + Such vacuums may allow portions of the table to be marked as + all visible and also allow tuples to be frozen, which + can reduce the work required in subsequent vacuums. + For tables which receive INSERT operations but no or + almost no UPDATE/DELETE operations, + it may be beneficial to lower the table's + as this may allow + tuples to be frozen by earlier vacuums. The number of obsolete tuples and + the number of inserted tuples are obtained from the cumulative statistics system; + it is a semi-accurate count updated by each UPDATE, + DELETE and INSERT operation. (It is + only semi-accurate because some information might be lost under heavy + load.) If the relfrozenxid value of the table + is more than vacuum_freeze_table_age transactions old, + an aggressive vacuum is performed to freeze old tuples and advance + relfrozenxid; otherwise, only pages that have been modified + since the last vacuum are scanned. + + + + For analyze, a similar condition is used: the threshold, defined as: + +analyze threshold = analyze base threshold + analyze scale factor * number of tuples + + is compared to the total number of tuples inserted, updated, or deleted + since the last ANALYZE. + + + + Partitioned tables are not processed by autovacuum. Statistics + should be collected by running a manual ANALYZE when it is + first populated, and again whenever the distribution of data in its + partitions changes significantly. + + + + Temporary tables cannot be accessed by autovacuum. Therefore, + appropriate vacuum and analyze operations should be performed via + session SQL commands. + + + + The default thresholds and scale factors are taken from + postgresql.conf, but it is possible to override them + (and many other autovacuum control parameters) on a per-table basis; see + for more information. + If a setting has been changed via a table's storage parameters, that value + is used when processing that table; otherwise the global settings are + used. See for more details on + the global settings. + + + + When multiple workers are running, the autovacuum cost delay parameters + (see ) are + balanced among all the running workers, so that the + total I/O impact on the system is the same regardless of the number + of workers actually running. However, any workers processing tables whose + per-table autovacuum_vacuum_cost_delay or + autovacuum_vacuum_cost_limit storage parameters have been set + are not considered in the balancing algorithm. + + + + Autovacuum workers generally don't block other commands. If a process + attempts to acquire a lock that conflicts with the + SHARE UPDATE EXCLUSIVE lock held by autovacuum, lock + acquisition will interrupt the autovacuum. For conflicting lock modes, + see . However, if the autovacuum + is running to prevent transaction ID wraparound (i.e., the autovacuum query + name in the pg_stat_activity view ends with + (to prevent wraparound)), the autovacuum is not + automatically interrupted. + + + + + Regularly running commands that acquire locks conflicting with a + SHARE UPDATE EXCLUSIVE lock (e.g., ANALYZE) can + effectively prevent autovacuums from ever completing. + + + + Routine Vacuuming @@ -749,172 +915,6 @@ HINT: Stop the postmaster and vacuum that database in single-user mode. - - - The Autovacuum Daemon - - - autovacuum - general information - - - PostgreSQL has an optional but highly - recommended feature called autovacuum, - whose purpose is to automate the execution of - VACUUM and ANALYZE commands. - When enabled, autovacuum checks for - tables that have had a large number of inserted, updated or deleted - tuples. These checks use the statistics collection facility; - therefore, autovacuum cannot be used unless is set to true. - In the default configuration, autovacuuming is enabled and the related - configuration parameters are appropriately set. - - - - The autovacuum daemon actually consists of multiple processes. - There is a persistent daemon process, called the - autovacuum launcher, which is in charge of starting - autovacuum worker processes for all databases. The - launcher will distribute the work across time, attempting to start one - worker within each database every - seconds. (Therefore, if the installation has N databases, - a new worker will be launched every - autovacuum_naptime/N seconds.) - A maximum of worker processes - are allowed to run at the same time. If there are more than - autovacuum_max_workers databases to be processed, - the next database will be processed as soon as the first worker finishes. - Each worker process will check each table within its database and - execute VACUUM and/or ANALYZE as needed. - can be set to monitor - autovacuum workers' activity. - - - - If several large tables all become eligible for vacuuming in a short - amount of time, all autovacuum workers might become occupied with - vacuuming those tables for a long period. This would result - in other tables and databases not being vacuumed until a worker becomes - available. There is no limit on how many workers might be in a - single database, but workers do try to avoid repeating work that has - already been done by other workers. Note that the number of running - workers does not count towards or - limits. - - - - Tables whose relfrozenxid value is more than - transactions old are always - vacuumed (this also applies to those tables whose freeze max age has - been modified via storage parameters; see below). Otherwise, if the - number of tuples obsoleted since the last - VACUUM exceeds the vacuum threshold, the - table is vacuumed. The vacuum threshold is defined as: - -vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples - - where the vacuum base threshold is - , - the vacuum scale factor is - , - and the number of tuples is - pg_class.reltuples. - - - - The table is also vacuumed if the number of tuples inserted since the last - vacuum has exceeded the defined insert threshold, which is defined as: - -vacuum insert threshold = vacuum base insert threshold + vacuum insert scale factor * number of tuples - - where the vacuum insert base threshold is - , - and vacuum insert scale factor is - . - Such vacuums may allow portions of the table to be marked as - all visible and also allow tuples to be frozen, which - can reduce the work required in subsequent vacuums. - For tables which receive INSERT operations but no or - almost no UPDATE/DELETE operations, - it may be beneficial to lower the table's - as this may allow - tuples to be frozen by earlier vacuums. The number of obsolete tuples and - the number of inserted tuples are obtained from the cumulative statistics system; - it is a semi-accurate count updated by each UPDATE, - DELETE and INSERT operation. (It is - only semi-accurate because some information might be lost under heavy - load.) If the relfrozenxid value of the table - is more than vacuum_freeze_table_age transactions old, - an aggressive vacuum is performed to freeze old tuples and advance - relfrozenxid; otherwise, only pages that have been modified - since the last vacuum are scanned. - - - - For analyze, a similar condition is used: the threshold, defined as: - -analyze threshold = analyze base threshold + analyze scale factor * number of tuples - - is compared to the total number of tuples inserted, updated, or deleted - since the last ANALYZE. - - - - Partitioned tables are not processed by autovacuum. Statistics - should be collected by running a manual ANALYZE when it is - first populated, and again whenever the distribution of data in its - partitions changes significantly. - - - - Temporary tables cannot be accessed by autovacuum. Therefore, - appropriate vacuum and analyze operations should be performed via - session SQL commands. - - - - The default thresholds and scale factors are taken from - postgresql.conf, but it is possible to override them - (and many other autovacuum control parameters) on a per-table basis; see - for more information. - If a setting has been changed via a table's storage parameters, that value - is used when processing that table; otherwise the global settings are - used. See for more details on - the global settings. - - - - When multiple workers are running, the autovacuum cost delay parameters - (see ) are - balanced among all the running workers, so that the - total I/O impact on the system is the same regardless of the number - of workers actually running. However, any workers processing tables whose - per-table autovacuum_vacuum_cost_delay or - autovacuum_vacuum_cost_limit storage parameters have been set - are not considered in the balancing algorithm. - - - - Autovacuum workers generally don't block other commands. If a process - attempts to acquire a lock that conflicts with the - SHARE UPDATE EXCLUSIVE lock held by autovacuum, lock - acquisition will interrupt the autovacuum. For conflicting lock modes, - see . However, if the autovacuum - is running to prevent transaction ID wraparound (i.e., the autovacuum query - name in the pg_stat_activity view ends with - (to prevent wraparound)), the autovacuum is not - automatically interrupted. - - - - - Regularly running commands that acquire locks conflicting with a - SHARE UPDATE EXCLUSIVE lock (e.g., ANALYZE) can - effectively prevent autovacuums from ever completing. - - - -- 2.40.0