SYNOPSIS
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ table ] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ]
DESCRIPTION Description
VACUUM recovery deleted storage space occupied by the tuple. In general PostgreSQL operation, after those tuples or tuples are already outdated UPDATE DELETE is not physically removed from the table to which they belong; they still exist prior to completion VACUUM. Therefore, we must have run periodically VACUUM, especially on the regular update of the table.
If there is no parameter, VACUUM deal with the current database for each table, if there are parameters, VACUUM deal only that table.
VACUUM ANALYZE first perform a VACUUM and then to each of the selected table to perform a ANALYZE. For routine maintenance scripts, this is a very convenient combination. See the ANALYZE [ the Analyze (7)] for more details about its processing.
Simple the VACUUM (without FULL) simply allowed to reclaim space and can be used again. This form of read and write commands and ordinary table parallel operations, since there is no request for an exclusive lock. VACUUM FULL perform more extensive processing, including cross-tuple block moves so as to compress the table number of disk blocks in minimum. This form much slower and needs to be applied on the treatment table at the time of an exclusive lock.
FREEZE is a special-purpose option that causes tuples as quickly labeled as "frozen (frozen)", rather than waiting until they are already quite old when it is marked. If there are no other transactions running on the same database when this command is completed, the system will ensure that all tuples in the database are "frozen (frozen)", and so there is no transaction ID wraparound problems, and and clean up the database is not the time does not matter. We do not recommend using the FREEZE everyday use. When we use it only to head to prepare templates and user-defined database connection, or other completely read-only, and will not wait for routine database maintenance VACUUM operations. See Chapter 21 `` Routine Database Maintenance '' for details.
PARAMETERS Parameters
- FULL
-
Select "completely" clean, so you can restore more space, but it takes more time and applying the exclusive lock on the table. - FREEZE
-
Select radical tuple "frozen." - VERBOSE
-
Print a detailed report for each table cleanup. - ANALYZE
-
Updated statistics for the optimizer to determine the most efficient way to execute a query. - table
-
To clean up the name of the table (schema-qualified). The default is the current database of all the tables. - column
-
Specific column to analyze / field names. The default is all columns / fields.
OUTPUTS Output
If you declare VERBOSE, VACUUM emits progress messages to indicate which table is currently being processed. All relevant statistical tables will be printed.
NOTES Note
We recommend regular continually failed to delete the row VACUUMM (cleanup) (at least once per night) production database to ensure. Especially after a large number of records additions and deletions, affected the implementation of VACUUM ANALYZE command table is a good habit. Doing so will update the system catalogs with recent changes, and allow the PostgreSQL query optimizer better choices in planning user queries.
We do not recommend routine use FULL option, but can be used in exceptional circumstances. One example is after you have deleted most of the rows in a table, hoping to narrow the list from the physical to reduce disk space usage. VACUUM FULL usually shrink the size of the table more than mere VACUUM.
EXAMPLES Examples
Here is an example of an executive VACUUM on a table in the regression (transformation) database:
regression=# VACUUM VERBOSE ANALYZE onek; INFO: vacuuming "public.onek" INFO: index "onek_unique1" now contains 1000 tuples in 14 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.18 sec. INFO: index "onek_unique2" now contains 1000 tuples in 16 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.07u sec elapsed 0.23 sec. INFO: index "onek_hundred" now contains 1000 tuples in 13 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.17 sec. INFO: index "onek_stringu1" now contains 1000 tuples in 48 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.09u sec elapsed 0.59 sec. INFO: "onek": removed 3000 tuples in 108 pages DETAIL: CPU 0.01s/0.06u sec elapsed 0.07 sec. INFO: "onek": found 3000 removable, 1000 nonremovable tuples in 143 pages DETAIL: 0 dead tuples cannot be removed yet. There were 0 unused item pointers. 0 pages are entirely empty. CPU 0.07s/0.39u sec elapsed 1.56 sec. INFO: analyzing "public.onek" INFO: "onek": 36 pages, 1000 rows sampled, 1000 estimated total rows VACUUM