ok
Direktori : /proc/thread-self/root/proc/self/root/opt/alt/postgresql11/usr/share/man/man7/ |
Current File : //proc/thread-self/root/proc/self/root/opt/alt/postgresql11/usr/share/man/man7/VACUUM.7 |
'\" t .\" Title: VACUUM .\" Author: The PostgreSQL Global Development Group .\" Generator: DocBook XSL Stylesheets v1.78.1 <http://docbook.sf.net/> .\" Date: 2017-11-06 .\" Manual: PostgreSQL 9.2.24 Documentation .\" Source: PostgreSQL 9.2.24 .\" Language: English .\" .TH "VACUUM" "7" "2017-11-06" "PostgreSQL 9.2.24" "PostgreSQL 9.2.24 Documentation" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" VACUUM \- garbage\-collect and optionally analyze a database .\" VACUUM .SH "SYNOPSIS" .sp .nf VACUUM [ ( { FULL | FREEZE | VERBOSE | ANALYZE } [, \&.\&.\&.] ) ] [ \fItable_name\fR [ (\fIcolumn_name\fR [, \&.\&.\&.] ) ] ] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ \fItable_name\fR ] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ \fItable_name\fR [ (\fIcolumn_name\fR [, \&.\&.\&.] ) ] ] .fi .SH "DESCRIPTION" .PP \fBVACUUM\fR reclaims storage occupied by dead tuples\&. In normal PostgreSQL operation, tuples that are deleted or obsoleted by an update are not physically removed from their table; they remain present until a \fBVACUUM\fR is done\&. Therefore it\*(Aqs necessary to do \fBVACUUM\fR periodically, especially on frequently\-updated tables\&. .PP With no parameter, \fBVACUUM\fR processes every table in the current database that the current user has permission to vacuum\&. With a parameter, \fBVACUUM\fR processes only that table\&. .PP \fBVACUUM ANALYZE\fR performs a \fBVACUUM\fR and then an \fBANALYZE\fR for each selected table\&. This is a handy combination form for routine maintenance scripts\&. See \fBANALYZE\fR(7) for more details about its processing\&. .PP Plain \fBVACUUM\fR (without FULL) simply reclaims space and makes it available for re\-use\&. This form of the command can operate in parallel with normal reading and writing of the table, as an exclusive lock is not obtained\&. However, extra space is not returned to the operating system (in most cases); it\*(Aqs just kept available for re\-use within the same table\&. \fBVACUUM FULL\fR rewrites the entire contents of the table into a new disk file with no extra space, allowing unused space to be returned to the operating system\&. This form is much slower and requires an exclusive lock on each table while it is being processed\&. .PP When the option list is surrounded by parentheses, the options can be written in any order\&. Without parentheses, options must be specified in exactly the order shown above\&. The parenthesized syntax was added in PostgreSQL 9\&.0; the unparenthesized syntax is deprecated\&. .SH "PARAMETERS" .PP FULL .RS 4 Selects \(lqfull\(rq vacuum, which can reclaim more space, but takes much longer and exclusively locks the table\&. This method also requires extra disk space, since it writes a new copy of the table and doesn\*(Aqt release the old copy until the operation is complete\&. Usually this should only be used when a significant amount of space needs to be reclaimed from within the table\&. .RE .PP FREEZE .RS 4 Selects aggressive \(lqfreezing\(rq of tuples\&. Specifying FREEZE is equivalent to performing \fBVACUUM\fR with the vacuum_freeze_min_age parameter set to zero\&. .RE .PP VERBOSE .RS 4 Prints a detailed vacuum activity report for each table\&. .RE .PP ANALYZE .RS 4 Updates statistics used by the planner to determine the most efficient way to execute a query\&. .RE .PP \fItable_name\fR .RS 4 The name (optionally schema\-qualified) of a specific table to vacuum\&. Defaults to all tables in the current database\&. .RE .PP \fIcolumn_name\fR .RS 4 The name of a specific column to analyze\&. Defaults to all columns\&. If a column list is specified, ANALYZE is implied\&. .RE .SH "OUTPUTS" .PP When VERBOSE is specified, \fBVACUUM\fR emits progress messages to indicate which table is currently being processed\&. Various statistics about the tables are printed as well\&. .SH "NOTES" .PP To vacuum a table, one must ordinarily be the table\*(Aqs owner or a superuser\&. However, database owners are allowed to vacuum all tables in their databases, except shared catalogs\&. (The restriction for shared catalogs means that a true database\-wide \fBVACUUM\fR can only be performed by a superuser\&.) \fBVACUUM\fR will skip over any tables that the calling user does not have permission to vacuum\&. .PP \fBVACUUM\fR cannot be executed inside a transaction block\&. .PP For tables with GIN indexes, \fBVACUUM\fR (in any form) also completes any pending index insertions, by moving pending index entries to the appropriate places in the main GIN index structure\&. See Section 55.3.1, \(lqGIN Fast Update Technique\(rq, in the documentation for details\&. .PP We recommend that active production databases be vacuumed frequently (at least nightly), in order to remove dead rows\&. After adding or deleting a large number of rows, it might be a good idea to issue a \fBVACUUM ANALYZE\fR command for the affected table\&. This will update the system catalogs with the results of all recent changes, and allow the PostgreSQL query planner to make better choices in planning queries\&. .PP The \fBFULL\fR option is not recommended for routine use, but might be useful in special cases\&. An example is when you have deleted or updated most of the rows in a table and would like the table to physically shrink to occupy less disk space and allow faster table scans\&. \fBVACUUM FULL\fR will usually shrink the table more than a plain \fBVACUUM\fR would\&. .PP \fBVACUUM\fR causes a substantial increase in I/O traffic, which might cause poor performance for other active sessions\&. Therefore, it is sometimes advisable to use the cost\-based vacuum delay feature\&. See Section 18.4.4, \(lqCost-based Vacuum Delay\(rq, in the documentation for details\&. .PP PostgreSQL includes an \(lqautovacuum\(rq facility which can automate routine vacuum maintenance\&. For more information about automatic and manual vacuuming, see Section 23.1, \(lqRoutine Vacuuming\(rq, in the documentation\&. .SH "EXAMPLES" .PP To clean a single table onek, analyze it for the optimizer and print a detailed vacuum activity report: .sp .if n \{\ .RS 4 .\} .nf VACUUM (VERBOSE, ANALYZE) onek; .fi .if n \{\ .RE .\} .SH "COMPATIBILITY" .PP There is no \fBVACUUM\fR statement in the SQL standard\&. .SH "SEE ALSO" \fBvacuumdb\fR(1), Section 18.4.4, \(lqCost-based Vacuum Delay\(rq, in the documentation, Section 23.1.6, \(lqThe Autovacuum Daemon\(rq, in the documentation