begriffs open source - ai-pg/blob - full-docs/txt/runtime-config-vacuum.txt

   1
   2 19.10. Vacuuming #
   3
   4    19.10.1. Automatic Vacuuming
   5    19.10.2. Cost-based Vacuum Delay
   6    19.10.3. Default Behavior
   7    19.10.4. Freezing
   8
   9    These parameters control vacuuming behavior. For more information on
  10    the purpose and responsibilities of vacuum, see Section 24.1.
  11
  12 19.10.1. Automatic Vacuuming #
  13
  14    These settings control the behavior of the autovacuum feature. Refer to
  15    Section 24.1.6 for more information. Note that many of these settings
  16    can be overridden on a per-table basis; see Storage Parameters.
  17
  18    autovacuum (boolean) #
  19           Controls whether the server should run the autovacuum launcher
  20           daemon. This is on by default; however, track_counts must also
  21           be enabled for autovacuum to work. This parameter can only be
  22           set in the postgresql.conf file or on the server command line;
  23           however, autovacuuming can be disabled for individual tables by
  24           changing table storage parameters.
  25
  26           Note that even when this parameter is disabled, the system will
  27           launch autovacuum processes if necessary to prevent transaction
  28           ID wraparound. See Section 24.1.5 for more information.
  29
  30    autovacuum_worker_slots (integer) #
  31           Specifies the number of backend slots to reserve for autovacuum
  32           worker processes. The default is typically 16 slots, but might
  33           be less if your kernel settings will not support it (as
  34           determined during initdb). This parameter can only be set at
  35           server start.
  36
  37           When changing this value, consider also adjusting
  38           autovacuum_max_workers.
  39
  40    autovacuum_max_workers (integer) #
  41           Specifies the maximum number of autovacuum processes (other than
  42           the autovacuum launcher) that may be running at any one time.
  43           The default is 3. This parameter can only be set in the
  44           postgresql.conf file or on the server command line.
  45
  46           Note that a setting for this value which is higher than
  47           autovacuum_worker_slots will have no effect, since autovacuum
  48           workers are taken from the pool of slots established by that
  49           setting.
  50
  51    autovacuum_naptime (integer) #
  52           Specifies the minimum delay between autovacuum runs on any given
  53           database. In each round the daemon examines the database and
  54           issues VACUUM and ANALYZE commands as needed for tables in that
  55           database. If this value is specified without units, it is taken
  56           as seconds. The default is one minute (1min). This parameter can
  57           only be set in the postgresql.conf file or on the server command
  58           line.
  59
  60    autovacuum_vacuum_threshold (integer) #
  61           Specifies the minimum number of updated or deleted tuples needed
  62           to trigger a VACUUM in any one table. The default is 50 tuples.
  63           This parameter can only be set in the postgresql.conf file or on
  64           the server command line; but the setting can be overridden for
  65           individual tables by changing table storage parameters.
  66
  67    autovacuum_vacuum_insert_threshold (integer) #
  68           Specifies the number of inserted tuples needed to trigger a
  69           VACUUM in any one table. The default is 1000 tuples. If -1 is
  70           specified, autovacuum will not trigger a VACUUM operation on any
  71           tables based on the number of inserts. This parameter can only
  72           be set in the postgresql.conf file or on the server command
  73           line; but the setting can be overridden for individual tables by
  74           changing table storage parameters.
  75
  76    autovacuum_analyze_threshold (integer) #
  77           Specifies the minimum number of inserted, updated or deleted
  78           tuples needed to trigger an ANALYZE in any one table. The
  79           default is 50 tuples. This parameter can only be set in the
  80           postgresql.conf file or on the server command line; but the
  81           setting can be overridden for individual tables by changing
  82           table storage parameters.
  83
  84    autovacuum_vacuum_scale_factor (floating point) #
  85           Specifies a fraction of the table size to add to
  86           autovacuum_vacuum_threshold when deciding whether to trigger a
  87           VACUUM. The default is 0.2 (20% of table size). This parameter
  88           can only be set in the postgresql.conf file or on the server
  89           command line; but the setting can be overridden for individual
  90           tables by changing table storage parameters.
  91
  92    autovacuum_vacuum_insert_scale_factor (floating point) #
  93           Specifies a fraction of the unfrozen pages in the table to add
  94           to autovacuum_vacuum_insert_threshold when deciding whether to
  95           trigger a VACUUM. The default is 0.2 (20% of unfrozen pages in
  96           table). This parameter can only be set in the postgresql.conf
  97           file or on the server command line; but the setting can be
  98           overridden for individual tables by changing table storage
  99           parameters.
 100
 101    autovacuum_analyze_scale_factor (floating point) #
 102           Specifies a fraction of the table size to add to
 103           autovacuum_analyze_threshold when deciding whether to trigger an
 104           ANALYZE. The default is 0.1 (10% of table size). This parameter
 105           can only be set in the postgresql.conf file or on the server
 106           command line; but the setting can be overridden for individual
 107           tables by changing table storage parameters.
 108
 109    autovacuum_vacuum_max_threshold (integer) #
 110           Specifies the maximum number of updated or deleted tuples needed
 111           to trigger a VACUUM in any one table, i.e., a limit on the value
 112           calculated with autovacuum_vacuum_threshold and
 113           autovacuum_vacuum_scale_factor. The default is 100,000,000
 114           tuples. If -1 is specified, autovacuum will not enforce a
 115           maximum number of updated or deleted tuples that will trigger a
 116           VACUUM operation. This parameter can only be set in the
 117           postgresql.conf file or on the server command line; but the
 118           setting can be overridden for individual tables by changing
 119           storage parameters.
 120
 121    autovacuum_freeze_max_age (integer) #
 122           Specifies the maximum age (in transactions) that a table's
 123           pg_class.relfrozenxid field can attain before a VACUUM operation
 124           is forced to prevent transaction ID wraparound within the table.
 125           Note that the system will launch autovacuum processes to prevent
 126           wraparound even when autovacuum is otherwise disabled.
 127
 128           Vacuum also allows removal of old files from the pg_xact
 129           subdirectory, which is why the default is a relatively low 200
 130           million transactions. This parameter can only be set at server
 131           start, but the setting can be reduced for individual tables by
 132           changing table storage parameters. For more information see
 133           Section 24.1.5.
 134
 135    autovacuum_multixact_freeze_max_age (integer) #
 136           Specifies the maximum age (in multixacts) that a table's
 137           pg_class.relminmxid field can attain before a VACUUM operation
 138           is forced to prevent multixact ID wraparound within the table.
 139           Note that the system will launch autovacuum processes to prevent
 140           wraparound even when autovacuum is otherwise disabled.
 141
 142           Vacuuming multixacts also allows removal of old files from the
 143           pg_multixact/members and pg_multixact/offsets subdirectories,
 144           which is why the default is a relatively low 400 million
 145           multixacts. This parameter can only be set at server start, but
 146           the setting can be reduced for individual tables by changing
 147           table storage parameters. For more information see
 148           Section 24.1.5.1.
 149
 150    autovacuum_vacuum_cost_delay (floating point) #
 151           Specifies the cost delay value that will be used in automatic
 152           VACUUM operations. If -1 is specified, the regular
 153           vacuum_cost_delay value will be used. If this value is specified
 154           without units, it is taken as milliseconds. The default value is
 155           2 milliseconds. This parameter can only be set in the
 156           postgresql.conf file or on the server command line; but the
 157           setting can be overridden for individual tables by changing
 158           table storage parameters.
 159
 160    autovacuum_vacuum_cost_limit (integer) #
 161           Specifies the cost limit value that will be used in automatic
 162           VACUUM operations. If -1 is specified (which is the default),
 163           the regular vacuum_cost_limit value will be used. Note that the
 164           value is distributed proportionally among the running autovacuum
 165           workers, if there is more than one, so that the sum of the
 166           limits for each worker does not exceed the value of this
 167           variable. This parameter can only be set in the postgresql.conf
 168           file or on the server command line; but the setting can be
 169           overridden for individual tables by changing table storage
 170           parameters.
 171
 172 19.10.2. Cost-based Vacuum Delay #
 173
 174    During the execution of VACUUM and ANALYZE commands, the system
 175    maintains an internal counter that keeps track of the estimated cost of
 176    the various I/O operations that are performed. When the accumulated
 177    cost reaches a limit (specified by vacuum_cost_limit), the process
 178    performing the operation will sleep for a short period of time, as
 179    specified by vacuum_cost_delay. Then it will reset the counter and
 180    continue execution.
 181
 182    The intent of this feature is to allow administrators to reduce the I/O
 183    impact of these commands on concurrent database activity. There are
 184    many situations where it is not important that maintenance commands
 185    like VACUUM and ANALYZE finish quickly; however, it is usually very
 186    important that these commands do not significantly interfere with the
 187    ability of the system to perform other database operations. Cost-based
 188    vacuum delay provides a way for administrators to achieve this.
 189
 190    This feature is disabled by default for manually issued VACUUM
 191    commands. To enable it, set the vacuum_cost_delay variable to a nonzero
 192    value.
 193
 194    vacuum_cost_delay (floating point) #
 195           The amount of time that the process will sleep when the cost
 196           limit has been exceeded. If this value is specified without
 197           units, it is taken as milliseconds. The default value is 0,
 198           which disables the cost-based vacuum delay feature. Positive
 199           values enable cost-based vacuuming.
 200
 201           When using cost-based vacuuming, appropriate values for
 202           vacuum_cost_delay are usually quite small, perhaps less than 1
 203           millisecond. While vacuum_cost_delay can be set to
 204           fractional-millisecond values, such delays may not be measured
 205           accurately on older platforms. On such platforms, increasing
 206           VACUUM's throttled resource consumption above what you get at
 207           1ms will require changing the other vacuum cost parameters. You
 208           should, nonetheless, keep vacuum_cost_delay as small as your
 209           platform will consistently measure; large delays are not
 210           helpful.
 211
 212    vacuum_cost_page_hit (integer) #
 213           The estimated cost for vacuuming a buffer found in the shared
 214           buffer cache. It represents the cost to lock the buffer pool,
 215           lookup the shared hash table and scan the content of the page.
 216           The default value is 1.
 217
 218    vacuum_cost_page_miss (integer) #
 219           The estimated cost for vacuuming a buffer that has to be read
 220           from disk. This represents the effort to lock the buffer pool,
 221           lookup the shared hash table, read the desired block in from the
 222           disk and scan its content. The default value is 2.
 223
 224    vacuum_cost_page_dirty (integer) #
 225           The estimated cost charged when vacuum modifies a block that was
 226           previously clean. It represents the extra I/O required to flush
 227           the dirty block out to disk again. The default value is 20.
 228
 229    vacuum_cost_limit (integer) #
 230           This is the accumulated cost that will cause the vacuuming
 231           process to sleep for vacuum_cost_delay. The default is 200.
 232
 233 Note
 234
 235    There are certain operations that hold critical locks and should
 236    therefore complete as quickly as possible. Cost-based vacuum delays do
 237    not occur during such operations. Therefore it is possible that the
 238    cost accumulates far higher than the specified limit. To avoid
 239    uselessly long delays in such cases, the actual delay is calculated as
 240    vacuum_cost_delay * accumulated_balance / vacuum_cost_limit with a
 241    maximum of vacuum_cost_delay * 4.
 242
 243 19.10.3. Default Behavior #
 244
 245    vacuum_truncate (boolean) #
 246           Enables or disables vacuum to try to truncate off any empty
 247           pages at the end of the table. The default value is true. If
 248           true, VACUUM and autovacuum do the truncation and the disk space
 249           for the truncated pages is returned to the operating system.
 250           Note that the truncation requires an ACCESS EXCLUSIVE lock on
 251           the table. The TRUNCATE parameter of VACUUM, if specified,
 252           overrides the value of this parameter. The setting can also be
 253           overridden for individual tables by changing table storage
 254           parameters.
 255
 256 19.10.4. Freezing #
 257
 258    To maintain correctness even after transaction IDs wrap around,
 259    PostgreSQL marks rows that are sufficiently old as frozen. These rows
 260    are visible to everyone; other transactions do not need to examine
 261    their inserting XID to determine visibility. VACUUM is responsible for
 262    marking rows as frozen. The following settings control VACUUM's
 263    freezing behavior and should be tuned based on the XID consumption rate
 264    of the system and data access patterns of the dominant workloads. See
 265    Section 24.1.5 for more information on transaction ID wraparound and
 266    tuning these parameters.
 267
 268    vacuum_freeze_table_age (integer) #
 269           VACUUM performs an aggressive scan if the table's
 270           pg_class.relfrozenxid field has reached the age specified by
 271           this setting. An aggressive scan differs from a regular VACUUM
 272           in that it visits every page that might contain unfrozen XIDs or
 273           MXIDs, not just those that might contain dead tuples. The
 274           default is 150 million transactions. Although users can set this
 275           value anywhere from zero to two billion, VACUUM will silently
 276           limit the effective value to 95% of autovacuum_freeze_max_age,
 277           so that a periodic manual VACUUM has a chance to run before an
 278           anti-wraparound autovacuum is launched for the table. For more
 279           information see Section 24.1.5.
 280
 281    vacuum_freeze_min_age (integer) #
 282           Specifies the cutoff age (in transactions) that VACUUM should
 283           use to decide whether to trigger freezing of pages that have an
 284           older XID. The default is 50 million transactions. Although
 285           users can set this value anywhere from zero to one billion,
 286           VACUUM will silently limit the effective value to half the value
 287           of autovacuum_freeze_max_age, so that there is not an
 288           unreasonably short time between forced autovacuums. For more
 289           information see Section 24.1.5.
 290
 291    vacuum_failsafe_age (integer) #
 292           Specifies the maximum age (in transactions) that a table's
 293           pg_class.relfrozenxid field can attain before VACUUM takes
 294           extraordinary measures to avoid system-wide transaction ID
 295           wraparound failure. This is VACUUM's strategy of last resort.
 296           The failsafe typically triggers when an autovacuum to prevent
 297           transaction ID wraparound has already been running for some
 298           time, though it's possible for the failsafe to trigger during
 299           any VACUUM.
 300
 301           When the failsafe is triggered, any cost-based delay that is in
 302           effect will no longer be applied, further non-essential
 303           maintenance tasks (such as index vacuuming) are bypassed, and
 304           any Buffer Access Strategy in use will be disabled resulting in
 305           VACUUM being free to make use of all of shared buffers.
 306
 307           The default is 1.6 billion transactions. Although users can set
 308           this value anywhere from zero to 2.1 billion, VACUUM will
 309           silently adjust the effective value to no less than 105% of
 310           autovacuum_freeze_max_age.
 311
 312    vacuum_multixact_freeze_table_age (integer) #
 313           VACUUM performs an aggressive scan if the table's
 314           pg_class.relminmxid field has reached the age specified by this
 315           setting. An aggressive scan differs from a regular VACUUM in
 316           that it visits every page that might contain unfrozen XIDs or
 317           MXIDs, not just those that might contain dead tuples. The
 318           default is 150 million multixacts. Although users can set this
 319           value anywhere from zero to two billion, VACUUM will silently
 320           limit the effective value to 95% of
 321           autovacuum_multixact_freeze_max_age, so that a periodic manual
 322           VACUUM has a chance to run before an anti-wraparound is launched
 323           for the table. For more information see Section 24.1.5.1.
 324
 325    vacuum_multixact_freeze_min_age (integer) #
 326           Specifies the cutoff age (in multixacts) that VACUUM should use
 327           to decide whether to trigger freezing of pages with an older
 328           multixact ID. The default is 5 million multixacts. Although
 329           users can set this value anywhere from zero to one billion,
 330           VACUUM will silently limit the effective value to half the value
 331           of autovacuum_multixact_freeze_max_age, so that there is not an
 332           unreasonably short time between forced autovacuums. For more
 333           information see Section 24.1.5.1.
 334
 335    vacuum_multixact_failsafe_age (integer) #
 336           Specifies the maximum age (in multixacts) that a table's
 337           pg_class.relminmxid field can attain before VACUUM takes
 338           extraordinary measures to avoid system-wide multixact ID
 339           wraparound failure. This is VACUUM's strategy of last resort.
 340           The failsafe typically triggers when an autovacuum to prevent
 341           transaction ID wraparound has already been running for some
 342           time, though it's possible for the failsafe to trigger during
 343           any VACUUM.
 344
 345           When the failsafe is triggered, any cost-based delay that is in
 346           effect will no longer be applied, and further non-essential
 347           maintenance tasks (such as index vacuuming) are bypassed.
 348
 349           The default is 1.6 billion multixacts. Although users can set
 350           this value anywhere from zero to 2.1 billion, VACUUM will
 351           silently adjust the effective value to no less than 105% of
 352           autovacuum_multixact_freeze_max_age.
 353
 354    vacuum_max_eager_freeze_failure_rate (floating point) #
 355           Specifies the maximum number of pages (as a fraction of total
 356           pages in the relation) that VACUUM may scan and fail to set
 357           all-frozen in the visibility map before disabling eager
 358           scanning. A value of 0 disables eager scanning altogether. The
 359           default is 0.03 (3%).
 360
 361           Note that when eager scanning is enabled, only freeze failures
 362           count against the cap, not successful freezing. Successful page
 363           freezes are capped internally at 20% of the all-visible but not
 364           all-frozen pages in the relation. Capping successful page
 365           freezes helps amortize the overhead across multiple normal
 366           vacuums and limits the potential downside of wasted eager
 367           freezes of pages that are modified again before the next
 368           aggressive vacuum.
 369
 370           This parameter can only be set in the postgresql.conf file or on
 371           the server command line; but the setting can be overridden for
 372           individual tables by changing the corresponding table storage
 373           parameter. For more information on tuning vacuum's freezing
 374           behavior, see Section 24.1.5.