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

   1
   2 VACUUM
   3
   4    VACUUM — garbage-collect and optionally analyze a database
   5
   6 Synopsis
   7
   8 VACUUM [ ( option [, ...] ) ] [ table_and_columns [, ...] ]
   9
  10 where option can be one of:
  11
  12     FULL [ boolean ]
  13     FREEZE [ boolean ]
  14     VERBOSE [ boolean ]
  15     ANALYZE [ boolean ]
  16     DISABLE_PAGE_SKIPPING [ boolean ]
  17     SKIP_LOCKED [ boolean ]
  18     INDEX_CLEANUP { AUTO | ON | OFF }
  19     PROCESS_MAIN [ boolean ]
  20     PROCESS_TOAST [ boolean ]
  21     TRUNCATE [ boolean ]
  22     PARALLEL integer
  23     SKIP_DATABASE_STATS [ boolean ]
  24     ONLY_DATABASE_STATS [ boolean ]
  25     BUFFER_USAGE_LIMIT size
  26
  27 and table_and_columns is:
  28
  29     [ ONLY ] table_name [ * ] [ ( column_name [, ...] ) ]
  30
  31 Description
  32
  33    VACUUM reclaims storage occupied by dead tuples. In normal PostgreSQL
  34    operation, tuples that are deleted or obsoleted by an update are not
  35    physically removed from their table; they remain present until a VACUUM
  36    is done. Therefore it's necessary to do VACUUM periodically, especially
  37    on frequently-updated tables.
  38
  39    Without a table_and_columns list, VACUUM processes every table and
  40    materialized view in the current database that the current user has
  41    permission to vacuum. With a list, VACUUM processes only those
  42    table(s).
  43
  44    VACUUM ANALYZE performs a VACUUM and then an ANALYZE for each selected
  45    table. This is a handy combination form for routine maintenance
  46    scripts. See ANALYZE for more details about its processing.
  47
  48    Plain VACUUM (without FULL) simply reclaims space and makes it
  49    available for re-use. This form of the command can operate in parallel
  50    with normal reading and writing of the table, as an exclusive lock is
  51    not obtained. However, extra space is not returned to the operating
  52    system (in most cases); it's just kept available for re-use within the
  53    same table. It also allows us to leverage multiple CPUs in order to
  54    process indexes. This feature is known as parallel vacuum. To disable
  55    this feature, one can use PARALLEL option and specify parallel workers
  56    as zero. VACUUM FULL rewrites the entire contents of the table into a
  57    new disk file with no extra space, allowing unused space to be returned
  58    to the operating system. This form is much slower and requires an
  59    ACCESS EXCLUSIVE lock on each table while it is being processed.
  60
  61 Parameters
  62
  63    FULL
  64           Selects “full” vacuum, which can reclaim more space, but takes
  65           much longer and exclusively locks the table. This method also
  66           requires extra disk space, since it writes a new copy of the
  67           table and doesn't release the old copy until the operation is
  68           complete. Usually this should only be used when a significant
  69           amount of space needs to be reclaimed from within the table.
  70
  71    FREEZE
  72           Selects aggressive “freezing” of tuples. Specifying FREEZE is
  73           equivalent to performing VACUUM with the vacuum_freeze_min_age
  74           and vacuum_freeze_table_age parameters set to zero. Aggressive
  75           freezing is always performed when the table is rewritten, so
  76           this option is redundant when FULL is specified.
  77
  78    VERBOSE
  79           Prints a detailed vacuum activity report for each table at INFO
  80           level.
  81
  82    ANALYZE
  83           Updates statistics used by the planner to determine the most
  84           efficient way to execute a query.
  85
  86    DISABLE_PAGE_SKIPPING
  87           Normally, VACUUM will skip pages based on the visibility map.
  88           Pages where all tuples are known to be frozen can always be
  89           skipped, and those where all tuples are known to be visible to
  90           all transactions may be skipped except when performing an
  91           aggressive vacuum. Furthermore, except when performing an
  92           aggressive vacuum, some pages may be skipped in order to avoid
  93           waiting for other sessions to finish using them. This option
  94           disables all page-skipping behavior, and is intended to be used
  95           only when the contents of the visibility map are suspect, which
  96           should happen only if there is a hardware or software issue
  97           causing database corruption.
  98
  99    SKIP_LOCKED
 100           Specifies that VACUUM should not wait for any conflicting locks
 101           to be released when beginning work on a relation: if a relation
 102           cannot be locked immediately without waiting, the relation is
 103           skipped. Note that even with this option, VACUUM may still block
 104           when opening the relation's indexes. Additionally, VACUUM
 105           ANALYZE may still block when acquiring sample rows from
 106           partitions, table inheritance children, and some types of
 107           foreign tables. Also, while VACUUM ordinarily processes all
 108           partitions of specified partitioned tables, this option will
 109           cause VACUUM to skip all partitions if there is a conflicting
 110           lock on the partitioned table.
 111
 112    INDEX_CLEANUP
 113           Normally, VACUUM will skip index vacuuming when there are very
 114           few dead tuples in the table. The cost of processing all of the
 115           table's indexes is expected to greatly exceed the benefit of
 116           removing dead index tuples when this happens. This option can be
 117           used to force VACUUM to process indexes when there are more than
 118           zero dead tuples. The default is AUTO, which allows VACUUM to
 119           skip index vacuuming when appropriate. If INDEX_CLEANUP is set
 120           to ON, VACUUM will conservatively remove all dead tuples from
 121           indexes. This may be useful for backwards compatibility with
 122           earlier releases of PostgreSQL where this was the standard
 123           behavior.
 124
 125           INDEX_CLEANUP can also be set to OFF to force VACUUM to always
 126           skip index vacuuming, even when there are many dead tuples in
 127           the table. This may be useful when it is necessary to make
 128           VACUUM run as quickly as possible to avoid imminent transaction
 129           ID wraparound (see Section 24.1.5). However, the wraparound
 130           failsafe mechanism controlled by vacuum_failsafe_age will
 131           generally trigger automatically to avoid transaction ID
 132           wraparound failure, and should be preferred. If index cleanup is
 133           not performed regularly, performance may suffer, because as the
 134           table is modified indexes will accumulate dead tuples and the
 135           table itself will accumulate dead line pointers that cannot be
 136           removed until index cleanup is completed.
 137
 138           This option has no effect for tables that have no index and is
 139           ignored if the FULL option is used. It also has no effect on the
 140           transaction ID wraparound failsafe mechanism. When triggered it
 141           will skip index vacuuming, even when INDEX_CLEANUP is set to ON.
 142
 143    PROCESS_MAIN
 144           Specifies that VACUUM should attempt to process the main
 145           relation. This is usually the desired behavior and is the
 146           default. Setting this option to false may be useful when it is
 147           only necessary to vacuum a relation's corresponding TOAST table.
 148
 149    PROCESS_TOAST
 150           Specifies that VACUUM should attempt to process the
 151           corresponding TOAST table for each relation, if one exists. This
 152           is usually the desired behavior and is the default. Setting this
 153           option to false may be useful when it is only necessary to
 154           vacuum the main relation. This option is required when the FULL
 155           option is used.
 156
 157    TRUNCATE
 158           Specifies that VACUUM should attempt to truncate off any empty
 159           pages at the end of the table and allow the disk space for the
 160           truncated pages to be returned to the operating system. This is
 161           normally the desired behavior and is the default unless
 162           vacuum_truncate is set to false or the vacuum_truncate option
 163           has been set to false for the table to be vacuumed. Setting this
 164           option to false may be useful to avoid ACCESS EXCLUSIVE lock on
 165           the table that the truncation requires. This option is ignored
 166           if the FULL option is used.
 167
 168    PARALLEL
 169           Perform index vacuum and index cleanup phases of VACUUM in
 170           parallel using integer background workers (for the details of
 171           each vacuum phase, please refer to Table 27.46). The number of
 172           workers used to perform the operation is equal to the number of
 173           indexes on the relation that support parallel vacuum which is
 174           limited by the number of workers specified with PARALLEL option
 175           if any which is further limited by
 176           max_parallel_maintenance_workers. An index can participate in
 177           parallel vacuum if and only if the size of the index is more
 178           than min_parallel_index_scan_size. Please note that it is not
 179           guaranteed that the number of parallel workers specified in
 180           integer will be used during execution. It is possible for a
 181           vacuum to run with fewer workers than specified, or even with no
 182           workers at all. Only one worker can be used per index. So
 183           parallel workers are launched only when there are at least 2
 184           indexes in the table. Workers for vacuum are launched before the
 185           start of each phase and exit at the end of the phase. These
 186           behaviors might change in a future release. This option can't be
 187           used with the FULL option.
 188
 189    SKIP_DATABASE_STATS
 190           Specifies that VACUUM should skip updating the database-wide
 191           statistics about oldest unfrozen XIDs. Normally VACUUM will
 192           update these statistics once at the end of the command. However,
 193           this can take awhile in a database with a very large number of
 194           tables, and it will accomplish nothing unless the table that had
 195           contained the oldest unfrozen XID was among those vacuumed.
 196           Moreover, if multiple VACUUM commands are issued in parallel,
 197           only one of them can update the database-wide statistics at a
 198           time. Therefore, if an application intends to issue a series of
 199           many VACUUM commands, it can be helpful to set this option in
 200           all but the last such command; or set it in all the commands and
 201           separately issue VACUUM (ONLY_DATABASE_STATS) afterwards.
 202
 203    ONLY_DATABASE_STATS
 204           Specifies that VACUUM should do nothing except update the
 205           database-wide statistics about oldest unfrozen XIDs. When this
 206           option is specified, the table_and_columns list must be empty,
 207           and no other option may be enabled except VERBOSE.
 208
 209    BUFFER_USAGE_LIMIT
 210           Specifies the Buffer Access Strategy ring buffer size for
 211           VACUUM. This size is used to calculate the number of shared
 212           buffers which will be reused as part of this strategy. 0
 213           disables use of a Buffer Access Strategy. If ANALYZE is also
 214           specified, the BUFFER_USAGE_LIMIT value is used for both the
 215           vacuum and analyze stages. This option can't be used with the
 216           FULL option except if ANALYZE is also specified. When this
 217           option is not specified, VACUUM uses the value from
 218           vacuum_buffer_usage_limit. Higher settings can allow VACUUM to
 219           run more quickly, but having too large a setting may cause too
 220           many other useful pages to be evicted from shared buffers. The
 221           minimum value is 128 kB and the maximum value is 16 GB.
 222
 223    boolean
 224           Specifies whether the selected option should be turned on or
 225           off. You can write TRUE, ON, or 1 to enable the option, and
 226           FALSE, OFF, or 0 to disable it. The boolean value can also be
 227           omitted, in which case TRUE is assumed.
 228
 229    integer
 230           Specifies a non-negative integer value passed to the selected
 231           option.
 232
 233    size
 234           Specifies an amount of memory in kilobytes. Sizes may also be
 235           specified as a string containing the numerical size followed by
 236           any one of the following memory units: B (bytes), kB
 237           (kilobytes), MB (megabytes), GB (gigabytes), or TB (terabytes).
 238
 239    table_name
 240           The name (optionally schema-qualified) of a specific table or
 241           materialized view to vacuum. If ONLY is specified before the
 242           table name, only that table is vacuumed. If ONLY is not
 243           specified, the table and all its inheritance child tables or
 244           partitions (if any) are also vacuumed. Optionally, * can be
 245           specified after the table name to explicitly indicate that
 246           inheritance child tables (or partitions) are to be vacuumed.
 247
 248    column_name
 249           The name of a specific column to analyze. Defaults to all
 250           columns. If a column list is specified, ANALYZE must also be
 251           specified.
 252
 253 Outputs
 254
 255    When VERBOSE is specified, VACUUM emits progress messages to indicate
 256    which table is currently being processed. Various statistics about the
 257    tables are printed as well.
 258
 259 Notes
 260
 261    To vacuum a table, one must ordinarily have the MAINTAIN privilege on
 262    the table. However, database owners are allowed to vacuum all tables in
 263    their databases, except shared catalogs. VACUUM will skip over any
 264    tables that the calling user does not have permission to vacuum.
 265
 266    While VACUUM is running, the search_path is temporarily changed to
 267    pg_catalog, pg_temp.
 268
 269    VACUUM cannot be executed inside a transaction block.
 270
 271    For tables with GIN indexes, VACUUM (in any form) also completes any
 272    pending index insertions, by moving pending index entries to the
 273    appropriate places in the main GIN index structure. See
 274    Section 65.4.4.1 for details.
 275
 276    We recommend that all databases be vacuumed regularly in order to
 277    remove dead rows. PostgreSQL includes an “autovacuum” facility which
 278    can automate routine vacuum maintenance. For more information about
 279    automatic and manual vacuuming, see Section 24.1.
 280
 281    The FULL option is not recommended for routine use, but might be useful
 282    in special cases. An example is when you have deleted or updated most
 283    of the rows in a table and would like the table to physically shrink to
 284    occupy less disk space and allow faster table scans. VACUUM FULL will
 285    usually shrink the table more than a plain VACUUM would.
 286
 287    The PARALLEL option is used only for vacuum purposes. If this option is
 288    specified with the ANALYZE option, it does not affect ANALYZE.
 289
 290    VACUUM causes a substantial increase in I/O traffic, which might cause
 291    poor performance for other active sessions. Therefore, it is sometimes
 292    advisable to use the cost-based vacuum delay feature. For parallel
 293    vacuum, each worker sleeps in proportion to the work done by that
 294    worker. See Section 19.10.2 for details.
 295
 296    Each backend running VACUUM without the FULL option will report its
 297    progress in the pg_stat_progress_vacuum view. Backends running VACUUM
 298    FULL will instead report their progress in the pg_stat_progress_cluster
 299    view. See Section 27.4.5 and Section 27.4.2 for details.
 300
 301 Examples
 302
 303    To clean a single table onek, analyze it for the optimizer and print a
 304    detailed vacuum activity report:
 305 VACUUM (VERBOSE, ANALYZE) onek;
 306
 307 Compatibility
 308
 309    There is no VACUUM statement in the SQL standard.
 310
 311    The following syntax was used before PostgreSQL version 9.0 and is
 312    still supported:
 313 VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ table_and_columns [, ...] ]
 314
 315    Note that in this syntax, the options must be specified in exactly the
 316    order shown.
 317
 318 See Also
 319
 320    vacuumdb, Section 19.10.2, Section 24.1.6, Section 27.4.5,
 321    Section 27.4.2