head	1.60;
access;
symbols
	REL9_0_0:1.60
	REL9_1_ALPHA1:1.60
	REL9_0_RC1:1.60
	REL9_0_BETA4:1.60
	REL9_0_STABLE:1.60.0.2
	REL9_0_BETA3:1.60
	REL9_0_BETA2:1.60
	REL7_4_29:1.33
	REL8_0_25:1.36
	REL8_1_21:1.40
	REL8_2_17:1.43.2.1
	REL8_3_11:1.51
	REL8_4_4:1.55
	REL9_0_BETA1:1.60
	REL9_0_ALPHA5_BRANCH:1.59.0.4
	REL9_0_ALPHA5:1.59
	REL7_4_28:1.33
	REL8_0_24:1.36
	REL8_1_20:1.40
	REL8_2_16:1.43.2.1
	REL8_3_10:1.51
	REL8_4_3:1.55
	REL9_0_ALPHA4:1.59
	REL9_0_ALPHA4_BRANCH:1.59.0.2
	REL8_5_ALPHA3:1.56
	REL8_5_ALPHA3_BRANCH:1.56.0.2
	REL7_4_27:1.33
	REL8_0_23:1.36
	REL8_1_19:1.40
	REL8_2_15:1.43.2.1
	REL8_3_9:1.51
	REL8_4_2:1.55
	REL8_5_ALPHA2:1.55
	REL8_5_ALPHA2_BRANCH:1.55.0.6
	REL7_4_26:1.33
	REL8_0_22:1.36
	REL8_1_18:1.40
	REL8_2_14:1.43.2.1
	REL8_3_8:1.51
	REL8_4_1:1.55
	REL8_5_ALPHA1:1.55
	REL8_5_ALPHA1_BRANCH:1.55.0.4
	REL8_4_STABLE:1.55.0.2
	REL8_4_0:1.55
	REL8_4_RC2:1.55
	REL8_4_RC1:1.55
	REL8_4_BETA2:1.55
	REL8_4_BETA1:1.55
	REL7_4_25:1.33
	REL8_0_21:1.36
	REL8_1_17:1.40
	REL8_2_13:1.43.2.1
	REL8_3_7:1.51
	REL7_4_24:1.33
	REL8_0_20:1.36
	REL8_1_16:1.40
	REL8_2_12:1.43.2.1
	REL8_3_6:1.51
	REL7_4_23:1.33
	REL8_0_19:1.36
	REL8_1_15:1.40
	REL8_2_11:1.43.2.1
	REL8_3_5:1.51
	REL7_4_22:1.33
	REL8_0_18:1.36
	REL8_1_14:1.40
	REL8_2_10:1.43.2.1
	REL8_3_4:1.51
	REL7_4_21:1.33
	REL8_0_17:1.36
	REL8_1_13:1.40
	REL8_2_9:1.43.2.1
	REL8_3_3:1.51
	REL7_4_20:1.33
	REL8_0_16:1.36
	REL8_1_12:1.40
	REL8_2_8:1.43.2.1
	REL8_3_2:1.51
	REL8_2_7:1.43.2.1
	REL8_3_1:1.51
	REL8_3_STABLE:1.51.0.2
	REL8_3_0:1.50
	REL8_3_RC2:1.50
	REL7_3_21:1.27
	REL7_4_19:1.33
	REL8_0_15:1.36
	REL8_1_11:1.40
	REL8_2_6:1.43.2.1
	REL8_3_RC1:1.50
	REL8_3_BETA4:1.50
	REL8_3_BETA3:1.49
	REL8_3_BETA2:1.49
	REL8_3_BETA1:1.48
	REL7_3_20:1.27
	REL7_4_18:1.33
	REL8_0_14:1.36
	REL8_1_10:1.40
	REL8_2_5:1.43.2.1
	REL7_3_19:1.27
	REL7_4_17:1.33
	REL8_0_13:1.36
	REL8_1_9:1.40
	REL8_2_4:1.43.2.1
	REL8_0_12:1.36
	REL8_1_8:1.40
	REL8_2_3:1.43.2.1
	REL7_3_18:1.27
	REL7_4_16:1.33
	REL8_0_11:1.36
	REL8_1_7:1.40
	REL8_2_2:1.43.2.1
	REL8_0_10:1.36
	REL8_1_6:1.40
	REL8_2_1:1.43
	REL7_4_15:1.33
	REL7_3_17:1.27
	REL8_2_STABLE:1.43.0.2
	REL8_2_0:1.43
	REL8_2_RC1:1.43
	REL8_2_BETA3:1.43
	REL8_2_BETA2:1.41
	REL8_1_5:1.40
	REL8_0_9:1.36
	REL7_4_14:1.33
	REL7_3_16:1.27
	REL8_2_BETA1:1.41
	REL7_3_15:1.27
	REL7_4_13:1.33
	REL8_0_8:1.36
	REL8_1_4:1.40
	REL7_3_14:1.27
	REL7_4_12:1.33
	REL8_0_7:1.36
	REL8_1_3:1.40
	REL7_3_13:1.27
	REL7_4_11:1.33
	REL8_0_6:1.36
	REL8_1_2:1.40
	REL7_3_12:1.27
	REL7_4_10:1.33
	REL8_0_5:1.36
	REL8_1_1:1.40
	REL8_1_STABLE:1.40.0.2
	REL8_1_0:1.40
	REL8_1_0RC1:1.39
	REL8_1_0BETA4:1.39
	REL8_1_0BETA3:1.39
	REL7_3_11:1.27
	REL7_4_9:1.33
	REL8_0_4:1.36
	REL8_1_0BETA2:1.39
	REL8_1_0BETA1:1.39
	REL7_2_8:1.22
	REL7_3_10:1.27
	REL7_4_8:1.33
	REL8_0_3:1.36
	REL8_0_2:1.36
	REL7_2_7:1.22
	REL7_3_9:1.27
	REL7_4_7:1.33
	REL8_0_1:1.36
	REL8_0_STABLE:1.36.0.4
	REL8_0_0:1.36.0.2
	REL8_0_0RC5:1.36
	REL8_0_0RC4:1.36
	REL8_0_0RC3:1.36
	REL8_0_0RC2:1.36
	REL8_0_0RC1:1.36
	REL8_0_0BETA5:1.35
	REL8_0_0BETA4:1.35
	REL7_4_6:1.33
	REL7_3_8:1.27
	REL7_2_6:1.22
	REL8_0_0BETA3:1.35
	REL8_0_0BETA2:1.35
	REL7_2_5:1.22
	REL7_4_5:1.33
	REL7_3_7:1.27
	REL7_4_4:1.33
	REL8_0_0BETA1:1.35
	REL7_4_3:1.33
	REL7_4_2:1.33
	REL7_3_6:1.27
	REL7_4_1:1.33
	REL7_3_5:1.27
	REL7_4:1.33
	REL7_4_RC2:1.33
	REL7_4_STABLE:1.33.0.2
	REL7_4_RC1:1.33
	REL7_4_BETA5:1.33
	REL7_4_BETA4:1.33
	REL7_4_BETA3:1.33
	REL7_4_BETA2:1.31
	WIN32_DEV:1.31.0.2
	REL7_4_BETA1:1.31
	REL7_3_4:1.27
	REL7_3_2:1.27
	REL7_2_4:1.22
	REL7_3_STABLE:1.27.0.2
	REL7_2_3:1.22
	REL7_2_STABLE:1.22.0.2
	REL7_2:1.22
	REL7_2_RC2:1.22
	REL7_2_RC1:1.22
	REL7_2_BETA5:1.22
	REL7_2_BETA4:1.22
	REL7_2_BETA3:1.21
	REL7_2_BETA2:1.20
	REL7_2_BETA1:1.20
	REL7_1_2:1.13
	REL7_1_STABLE:1.13.0.2
	REL7_1_BETA:1.12
	REL7_1_BETA3:1.12
	REL7_1_BETA2:1.12
	REL7_1:1.13
	REL7_0_PATCHES:1.9.0.2
	REL7_0:1.9
	REL6_5_PATCHES:1.3.0.2
	REL6_5:1.3
	REL6_4:1.1.0.2;
locks; strict;
comment	@# @;


1.60
date	2010.04.03.07.23.02;	author petere;	state Exp;
branches;
next	1.59;

1.59
date	2010.02.17.04.19.39;	author tgl;	state Exp;
branches;
next	1.58;

1.58
date	2010.02.08.04.33.51;	author tgl;	state Exp;
branches;
next	1.57;

1.57
date	2010.01.06.05.31.13;	author itagaki;	state Exp;
branches;
next	1.56;

1.56
date	2009.11.16.21.32.06;	author tgl;	state Exp;
branches;
next	1.55;

1.55
date	2009.03.24.20.17.08;	author tgl;	state Exp;
branches;
next	1.54;

1.54
date	2008.12.11.18.16.18;	author tgl;	state Exp;
branches;
next	1.53;

1.53
date	2008.11.14.10.22.47;	author petere;	state Exp;
branches;
next	1.52;

1.52
date	2008.09.30.10.52.10;	author heikki;	state Exp;
branches;
next	1.51;

1.51
date	2008.02.03.16.24.08;	author tgl;	state Exp;
branches;
next	1.50;

1.50
date	2007.11.28.05.01.24;	author momjian;	state Exp;
branches;
next	1.49;

1.49
date	2007.10.07.01.16.42;	author alvherre;	state Exp;
branches;
next	1.48;

1.48
date	2007.05.30.19.45.01;	author momjian;	state Exp;
branches;
next	1.47;

1.47
date	2007.01.31.23.26.04;	author momjian;	state Exp;
branches;
next	1.46;

1.46
date	2007.01.31.04.13.22;	author momjian;	state Exp;
branches;
next	1.45;

1.45
date	2006.12.27.14.55.17;	author momjian;	state Exp;
branches;
next	1.44;

1.44
date	2006.12.23.01.58.40;	author momjian;	state Exp;
branches;
next	1.43;

1.43
date	2006.11.05.22.42.07;	author tgl;	state Exp;
branches
	1.43.2.1;
next	1.42;

1.42
date	2006.10.31.01.52.31;	author neilc;	state Exp;
branches;
next	1.41;

1.41
date	2006.09.16.00.30.20;	author momjian;	state Exp;
branches;
next	1.40;

1.40
date	2005.11.01.21.09.51;	author tgl;	state Exp;
branches;
next	1.39;

1.39
date	2005.07.30.17.15.35;	author momjian;	state Exp;
branches;
next	1.38;

1.38
date	2005.07.30.17.03.56;	author momjian;	state Exp;
branches;
next	1.37;

1.37
date	2005.07.30.15.45.49;	author momjian;	state Exp;
branches;
next	1.36;

1.36
date	2004.12.02.19.28.48;	author tgl;	state Exp;
branches;
next	1.35;

1.35
date	2004.03.23.13.21.41;	author neilc;	state Exp;
branches;
next	1.34;

1.34
date	2003.11.29.19.51.39;	author pgsql;	state Exp;
branches;
next	1.33;

1.33
date	2003.09.12.00.12.47;	author tgl;	state Exp;
branches;
next	1.32;

1.32
date	2003.08.31.17.32.24;	author petere;	state Exp;
branches;
next	1.31;

1.31
date	2003.04.26.23.56.51;	author petere;	state Exp;
branches
	1.31.2.1;
next	1.30;

1.30
date	2003.03.25.16.15.44;	author petere;	state Exp;
branches;
next	1.29;

1.29
date	2003.02.19.04.06.28;	author momjian;	state Exp;
branches;
next	1.28;

1.28
date	2003.01.19.00.13.31;	author momjian;	state Exp;
branches;
next	1.27;

1.27
date	2002.10.09.16.27.48;	author momjian;	state Exp;
branches;
next	1.26;

1.26
date	2002.09.21.18.32.54;	author petere;	state Exp;
branches;
next	1.25;

1.25
date	2002.04.23.02.07.16;	author tgl;	state Exp;
branches;
next	1.24;

1.24
date	2002.04.21.19.02.39;	author thomas;	state Exp;
branches;
next	1.23;

1.23
date	2002.03.06.06.48.05;	author momjian;	state Exp;
branches;
next	1.22;

1.22
date	2001.12.08.03.24.39;	author thomas;	state Exp;
branches;
next	1.21;

1.21
date	2001.11.18.22.17.30;	author tgl;	state Exp;
branches;
next	1.20;

1.20
date	2001.10.12.23.34.30;	author momjian;	state Exp;
branches;
next	1.19;

1.19
date	2001.09.03.12.57.50;	author petere;	state Exp;
branches;
next	1.18;

1.18
date	2001.08.26.16.55.59;	author tgl;	state Exp;
branches;
next	1.17;

1.17
date	2001.07.10.22.09.28;	author tgl;	state Exp;
branches;
next	1.16;

1.16
date	2001.05.25.15.45.31;	author momjian;	state Exp;
branches;
next	1.15;

1.15
date	2001.05.25.15.34.49;	author momjian;	state Exp;
branches;
next	1.14;

1.14
date	2001.05.07.00.43.15;	author tgl;	state Exp;
branches;
next	1.13;

1.13
date	2001.01.13.23.58.55;	author petere;	state Exp;
branches;
next	1.12;

1.12
date	2000.10.05.19.57.23;	author momjian;	state Exp;
branches;
next	1.11;

1.11
date	2000.10.05.19.48.19;	author momjian;	state Exp;
branches;
next	1.10;

1.10
date	2000.09.12.21.12.45;	author momjian;	state Exp;
branches;
next	1.9;

1.9
date	2000.04.14.17.37.54;	author momjian;	state Exp;
branches;
next	1.8;

1.8
date	2000.04.05.21.51.11;	author momjian;	state Exp;
branches;
next	1.7;

1.7
date	99.12.07.22.41.41;	author momjian;	state Exp;
branches;
next	1.6;

1.6
date	99.11.28.02.17.04;	author tgl;	state Exp;
branches;
next	1.5;

1.5
date	99.07.22.15.09.15;	author thomas;	state Exp;
branches;
next	1.4;

1.4
date	99.07.14.20.32.59;	author thomas;	state Exp;
branches;
next	1.3;

1.3
date	98.12.29.02.24.47;	author thomas;	state Exp;
branches;
next	1.2;

1.2
date	98.11.14.02.02.53;	author thomas;	state Exp;
branches;
next	1.1;

1.1
date	98.10.05.02.54.45;	author thomas;	state Exp;
branches;
next	;

1.31.2.1
date	2003.09.07.04.36.46;	author momjian;	state Exp;
branches;
next	;

1.43.2.1
date	2007.01.31.04.13.28;	author momjian;	state Exp;
branches;
next	;


desc
@@


1.60
log
@Remove unnecessary xref endterm attributes and title ids

The endterm attribute is mainly useful when the toolchain does not support
automatic link target text generation for a particular situation.  In  the
past, this was required by the man page tools for all reference page links,
but that is no longer the case, and it now actually gets in the way of
proper automatic link text generation.  The only remaining use cases are
currently xrefs to refsects.
@
text
@<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.59 2010/02/17 04:19:39 tgl Exp $
PostgreSQL documentation
-->

<refentry id="SQL-VACUUM">
 <refmeta>
  <refentrytitle>VACUUM</refentrytitle>
  <manvolnum>7</manvolnum>
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 </refmeta>

 <refnamediv>
  <refname>VACUUM</refname>
  <refpurpose>garbage-collect and optionally analyze a database</refpurpose>
 </refnamediv>

 <indexterm zone="sql-vacuum">
  <primary>VACUUM</primary>
 </indexterm>

 <refsynopsisdiv>
<synopsis>
VACUUM [ ( { FULL | FREEZE | VERBOSE | ANALYZE } [, ...] ) ] [ <replaceable class="PARAMETER">table</replaceable> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ <replaceable class="PARAMETER">table</replaceable> ]
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">table</replaceable> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
</synopsis>
 </refsynopsisdiv>

 <refsect1>
  <title>Description</title>

  <para>
   <command>VACUUM</command> reclaims storage occupied by dead tuples.
   In normal <productname>PostgreSQL</productname> operation, tuples that
   are deleted or obsoleted by an update are not physically removed from
   their table; they remain present until a <command>VACUUM</command> is
   done.  Therefore it's necessary to do <command>VACUUM</command>
   periodically, especially on frequently-updated tables.
  </para>

  <para>
   With no parameter, <command>VACUUM</command> processes every table in the
   current database that the current user has permission to vacuum.
   With a parameter, <command>VACUUM</command> processes only that table.
  </para>

  <para>
   <command>VACUUM ANALYZE</command> performs a <command>VACUUM</command>
   and then an <command>ANALYZE</command> for each selected table.  This
   is a handy combination form for routine maintenance scripts.  See
   <xref linkend="sql-analyze">
   for more details about its processing.
  </para>

  <para>
   Plain <command>VACUUM</command> (without <literal>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's just kept available for re-use within the
   same table.  <command>VACUUM FULL</command> 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.
  </para>

  <para>
   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.
   Prior to <productname>PostgreSQL</productname> 9.0, the unparenthesized
   syntax was the only one supported.  It is expected that all new options
   will be supported only in the parenthesized syntax.
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

  <variablelist>
   <varlistentry>
    <term><literal>FULL</literal></term>
    <listitem>
     <para>
      Selects <quote>full</quote> 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't 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.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>FREEZE</literal></term>
    <listitem>
     <para>
      Selects aggressive <quote>freezing</quote> of tuples.
      Specifying <literal>FREEZE</literal> is equivalent to performing
      <command>VACUUM</command> with the
      <xref linkend="guc-vacuum-freeze-min-age"> parameter
      set to zero.  The <literal>FREEZE</literal> option is deprecated and
      will be removed in a future release; set the parameter instead.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>VERBOSE</literal></term>
    <listitem>
     <para>
      Prints a detailed vacuum activity report for each table.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>ANALYZE</literal></term>
    <listitem>
     <para>
      Updates statistics used by the planner to determine the most
      efficient way to execute a query.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="PARAMETER">table</replaceable></term>
    <listitem>
     <para>
      The name (optionally schema-qualified) of a specific table to
      vacuum. Defaults to all tables in the current database.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="PARAMETER">column</replaceable></term>
    <listitem>
     <para>
      The name of a specific column to analyze. Defaults to all columns.
      If a column list is specified, <literal>ANALYZE</> is implied.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1>
  <title>Outputs</title>

   <para>
    When <literal>VERBOSE</> is specified, <command>VACUUM</> emits
    progress messages to indicate which table is currently being
    processed.  Various statistics about the tables are printed as well.
   </para>
 </refsect1>

 <refsect1>
  <title>Notes</title>

   <para>
    To vacuum a table, one must ordinarily be the table's 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
    <command>VACUUM</> can only be performed by a superuser.)
    <command>VACUUM</> will skip over any tables that the calling user
    does not have permission to vacuum.
   </para>

   <para>
    <command>VACUUM</> cannot be executed inside a transaction block.
   </para>

   <para>
    For tables with <acronym>GIN</> indexes, <command>VACUUM</command> (in
    any form) also completes any pending index insertions, by moving pending
    index entries to the appropriate places in the main <acronym>GIN</> index
    structure.  See <xref linkend="gin-fast-update"> for details.
   </para>

   <para>
    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 <command>VACUUM
    ANALYZE</command> command for the affected table. This will update the
    system catalogs with
    the results of all recent changes, and allow the
    <productname>PostgreSQL</productname> query planner to make better
    choices in planning queries.
   </para>

   <para>
    The <option>FULL</option> 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. <command>VACUUM FULL</command> will usually shrink the table
    more than a plain <command>VACUUM</command> would.
   </para>

   <para>
    <command>VACUUM</command> 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 <xref linkend="runtime-config-resource-vacuum-cost"> for details.
   </para>

   <para>
    <productname>PostgreSQL</productname> includes an <quote>autovacuum</>
    facility which can automate routine vacuum maintenance.  For more
    information about automatic and manual vacuuming, see
    <xref linkend="routine-vacuuming">.
   </para>
 </refsect1>

 <refsect1>
  <title>Examples</title>

  <para>
   The following is an example from running <command>VACUUM</command> on a
   table in the regression database:

<programlisting>
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
</programlisting>
  </para>
 </refsect1>

 <refsect1>
  <title>Compatibility</title>

  <para>
   There is no <command>VACUUM</command> statement in the SQL standard.
  </para>
 </refsect1>

 <refsect1>
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="app-vacuumdb"></member>
   <member><xref linkend="runtime-config-resource-vacuum-cost"></member>
   <member><xref linkend="autovacuum"></member>
  </simplelist>
 </refsect1>
</refentry>
@


1.59
log
@Stamp HEAD as 9.0devel, and update various places that were referring to 8.5
(hope I got 'em all).  Per discussion, this release will be 9.0 not 8.5.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.58 2010/02/08 04:33:51 tgl Exp $
d8 1
a8 1
  <refentrytitle id="sql-vacuum-title">VACUUM</refentrytitle>
d52 1
a52 1
   <xref linkend="sql-analyze" endterm="sql-analyze-title">
d274 3
a276 3
   <member><xref linkend="app-vacuumdb" endterm="app-vacuumdb-title"></member>
   <member><xref linkend="runtime-config-resource-vacuum-cost" endterm="runtime-config-resource-vacuum-cost-title"></member>
   <member><xref linkend="autovacuum" endterm="autovacuum-title"></member>
@


1.58
log
@Remove old-style VACUUM FULL (which was known for a little while as
VACUUM FULL INPLACE), along with a boatload of subsidiary code and complexity.
Per discussion, the use case for this method of vacuuming is no longer large
enough to justify maintaining it; not to mention that we don't wish to invest
the work that would be needed to make it play nicely with Hot Standby.

Aside from the code directly related to old-style VACUUM FULL, this commit
removes support for certain WAL record types that could only be generated
within VACUUM FULL, redirect-pointer removal in heap_page_prune, and
nontransactional generation of cache invalidation sinval messages (the last
being the sticking point for Hot Standby).

We still have to retain all code that copes with finding HEAP_MOVED_OFF and
HEAP_MOVED_IN flag bits on existing tuples.  This can't be removed as long
as we want to support in-place update from pre-9.0 databases.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.57 2010/01/06 05:31:13 itagaki Exp $
d73 1
a73 1
   Prior to <productname>PostgreSQL</productname> 8.5, the unparenthesized
@


1.57
log
@Support rewritten-based full vacuum as VACUUM FULL. Traditional
VACUUM FULL was renamed to VACUUM FULL INPLACE. Also added a new
option -i, --inplace for vacuumdb to perform FULL INPLACE vacuuming.

Since the new VACUUM FULL uses CLUSTER infrastructure, we cannot
use it for system tables. VACUUM FULL for system tables always
fall back into VACUUM FULL INPLACE silently.

Itagaki Takahiro, reviewed by Jeff Davis and Simon Riggs.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.56 2009/11/16 21:32:06 tgl Exp $
d24 1
a24 1
VACUUM [ ( { FULL [ INPLACE ] | FREEZE | VERBOSE | ANALYZE } [, ...] ) ] [ <replaceable class="PARAMETER">table</replaceable> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
d61 6
a66 5
   is not obtained. <command>VACUUM
   FULL</command> does more extensive processing, including moving of tuples
   across blocks to try to compact the table to the minimum number of disk
   blocks.  This form is much slower and requires an exclusive lock on each
   table while it is being processed.
d89 4
a92 21
     </para>
     <para>
      For user tables, all table data and indexes are rewritten. This
      method requires extra disk space in which to write the new data,
      and is generally useful when a significant amount of space needs
      to be reclaimed from within the table.
     </para>
     <para>
      For system tables, all table data and indexes are modified in
      place to reclaim space. This method may require less disk space
      for the table data than <command>VACUUM FULL</command> on a
      comparable user table, but the indexes will grow which may
      counteract that benefit. Additionally, the operation is often
      slower than <command>VACUUM FULL</command> on a comparable user
      table.
     </para>
     <para>
      If <literal>FULL INPLACE</literal> is specified, the space is
      reclaimed in the same manner as a system table, even if it is a
      user table. Specifying <literal>INPLACE</literal> explicitly is
      rarely useful.
d204 1
a204 4
    more than a plain <command>VACUUM</command> would.  The
    <option>FULL</option> option does not shrink indexes; a periodic
    <command>REINDEX</> is still recommended.  In fact, it is often faster
    to drop all indexes, <command>VACUUM FULL</>, and recreate the indexes.
@


1.56
log
@Provide a parenthesized-options syntax for VACUUM, analogous to that recently
adopted for EXPLAIN.  This will allow additional options to be implemented
in future without having to make them fully-reserved keywords.  The old syntax
remains available for existing options, however.

Itagaki Takahiro
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.55 2009/03/24 20:17:08 tgl Exp $
d24 1
a24 1
VACUUM [ ( { FULL | FREEZE | VERBOSE | ANALYZE } [, ...] ) ] [ <replaceable class="PARAMETER">table</replaceable> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
d89 21
@


1.55
log
@Implement "fastupdate" support for GIN indexes, in which we try to accumulate
multiple index entries in a holding area before adding them to the main index
structure.  This helps because bulk insert is (usually) significantly faster
than retail insert for GIN.

This patch also removes GIN support for amgettuple-style index scans.  The
API defined for amgettuple is difficult to support with fastupdate, and
the previously committed partial-match feature didn't really work with
it either.  We might eventually figure a way to put back amgettuple
support, but it won't happen for 8.4.

catversion bumped because of change in GIN's pg_am entry, and because
the format of GIN indexes changed on-disk (there's a metapage now,
and possibly a pending list).

Teodor Sigaev
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.54 2008/12/11 18:16:18 tgl Exp $
d24 1
d67 9
d140 1
d228 1
a228 1
regression=# VACUUM VERBOSE ANALYZE onek;
@


1.54
log
@To reduce confusion over whether VACUUM FULL is needed for anti-wraparound
vacuuming (it's not), say "database-wide VACUUM" instead of "full-database
VACUUM" in the relevant hint messages.  Also, document the permissions needed
to do this.  Per today's discussion.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.53 2008/11/14 10:22:47 petere Exp $
d164 7
@


1.53
log
@Set SQL man pages to be section 7 by default, and only transform them to
another section if required by the platform (instead of the old way of
building them in section "l" and always transforming them to the
platform-specific section).

This speeds up the installation on common platforms, and it avoids some
funny business with the man page tools and build process.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.52 2008/09/30 10:52:10 heikki Exp $
d43 2
a44 2
   current database.  With a parameter, <command>VACUUM</command> processes
   only that table.
d150 10
@


1.52
log
@Rewrite the FSM. Instead of relying on a fixed-size shared memory segment, the
free space information is stored in a dedicated FSM relation fork, with each
relation (except for hash indexes; they don't use FSM).

This eliminates the max_fsm_relations and max_fsm_pages GUC options; remove any
trace of them from the backend, initdb, and documentation.

Rewrite contrib/pg_freespacemap to match the new FSM implementation. Also
introduce a new variant of the get_raw_page(regclass, int4, int4) function in
contrib/pageinspect that let's you to return pages from any relation fork, and
a new fsm_page_contents() function to inspect the new FSM pages.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.51 2008/02/03 16:24:08 tgl Exp $
d9 1
@


1.51
log
@Fix mistaken duplicate reference to max_fsm_pages, per bug #3926.
Also make links clickable.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.50 2007/11/28 05:01:24 momjian Exp $
d99 1
a99 5
      Prints a detailed vacuum activity report for each table. Can be used
      to help determine appropriate settings for
      <xref linkend="guc-max-fsm-pages">,
      <xref linkend="guc-max-fsm-relations">, and
      <xref linkend="guc-default-statistics-target">.
@


1.50
log
@Add comments about VACUUM to free space map docs.

Joshua D. Drake
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.49 2007/10/07 01:16:42 alvherre Exp $
d101 3
a103 2
      <literal>max_fsm_pages</literal>, <literal>max_fsm_pages</literal>,
      and <literal>default_statistics_target</literal>.
@


1.49
log
@A few improvements to analyze and vacuum sections in documentation: add "see
also" entries for autovacuum in analyze and vacuum reference pages, and
enhance usage of cross-references in the maintenance page.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.48 2007/05/30 19:45:01 momjian Exp $
d99 4
a102 1
      Prints a detailed vacuum activity report for each table.
@


1.48
log
@Update documentation mention of VACUUM FULL and CLUSTER where
appropriate.

Guillaume Cottenceau
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.47 2007/01/31 23:26:04 momjian Exp $
d245 1
@


1.47
log
@Update reference documentation on may/can/might:

Standard English uses "may", "can", and "might" in different ways:

        may - permission, "You may borrow my rake."

        can - ability, "I can lift that log."

        might - possibility, "It might rain today."

Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice.  Similarly, "It may crash" is better stated, "It might crash".
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.46 2007/01/31 04:13:22 momjian Exp $
d167 5
a171 4
    most of the rows in a table and would like the table to physically shrink
    to occupy less disk space.  <command>VACUUM FULL</command> will usually
    shrink the table more than a plain <command>VACUUM</command> would.
    The <option>FULL</option> option does not shrink indexes; a periodic
@


1.46
log
@Document need for periodic REINDEX in VACUUM FULL cases.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.45 2006/12/27 14:55:17 momjian Exp $
d75 1
a75 1
      Selects <quote>full</quote> vacuum, which may reclaim more
d156 1
a156 1
    of rows, it may be a good idea to issue a <command>VACUUM
d166 1
a166 1
    but may be useful in special cases.  An example is when you have deleted
d177 1
a177 1
    which can cause poor performance for other active sessions.  Therefore,
@


1.45
log
@Use "dead" rather than "expired" for vacuumable rows.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.44 2006/12/23 01:58:40 momjian Exp $
d170 3
@


1.44
log
@Change a VACUUM manual page word from 'deleted' to 'expired', so DELETE
and UPDATE are clearly covered by the term.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.43 2006/11/05 22:42:07 tgl Exp $
d32 1
a32 1
   <command>VACUUM</command> reclaims storage occupied by expired tuples.
d155 1
a155 1
    remove expired rows. After adding or deleting a large number
@


1.43
log
@Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios.  We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases.  Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId.  Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done.  Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database.  initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs.  Heikki Linnakangas, Simon Riggs, and Tom Lane.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.42 2006/10/31 01:52:31 neilc Exp $
d32 1
a32 1
   <command>VACUUM</command> reclaims storage occupied by deleted tuples.
@


1.43.2.1
log
@Document need for periodic REINDEX in VACUUM FULL cases.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.43 2006/11/05 22:42:07 tgl Exp $
a169 3
    The <option>FULL</option> option does not shrink indexes; a periodic
    <command>REINDEX</> is still recommended.  In fact, it is often faster
    to drop all indexes, <command>VACUUM FULL</>, and recreate the indexes.
@


1.42
log
@Add text to the VACUUM, REINDEX, DROP TABLESPACE and CREATE TABLESPACE
reference pages documenting that these commands cannot be used within
a transaction block. Also make some minor improvements to the psql
reference page. Patch from Simon Riggs, minor editorialization by
myself.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.41 2006/09/16 00:30:20 momjian Exp $
d23 2
a24 2
VACUUM [ FULL | FREEZE ] [ VERBOSE ] [ <replaceable class="PARAMETER">table</replaceable> ]
VACUUM [ FULL | FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">table</replaceable> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
a64 15

  <para>
   <literal>FREEZE</literal> is a special-purpose option that
   causes tuples to be marked <quote>frozen</quote> as soon as possible,
   rather than waiting until they are quite old.  If this is done when there
   are no other open transactions in the same database, then it is guaranteed
   that all tuples in the database are <quote>frozen</> and will not be
   subject to transaction ID wraparound problems, no matter how long the
   database is left unvacuumed.
   <literal>FREEZE</literal> is not recommended for routine use.  Its only
   intended usage is in connection with preparation of user-defined template
   databases, or other databases that are completely read-only and will not
   receive routine maintenance <command>VACUUM</> operations.
   See <xref linkend="maintenance"> for details.
  </para>
d86 5
d178 7
@


1.41
log
@Remove emacs info from footer of SGML files.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.40 2005/11/01 21:09:51 tgl Exp $
d159 4
@


1.40
log
@Make an editorial pass over the reference pages.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.39 2005/07/30 17:15:35 momjian Exp $
a242 17

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"../reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:"/usr/lib/sgml/catalog"
sgml-local-ecat-files:nil
End:
-->
@


1.39
log
@More vacuum markup fixes.  Alvaro
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.37 2005/07/30 15:45:49 momjian Exp $
d179 4
a182 6
    During <command>VACUUM</command> execution, there can be a substantial
    increase in I/O traffic, which cause poor performance for other active
    sessions.  Therefore, it is sometimes advisable to use
    the cost-based vacuum delay feature.  See <xref
    linkend="runtime" endterm="runtime-config-resource-vacuum-cost-title"> for more
    details.
d239 1
a239 1
   <member><xref linkend="runtime" endterm="runtime-config-resource-vacuum-cost-title"></member>
@


1.38
log
@Fix VACUUM sgml markup.
@
text
@d183 1
a183 1
    linkend="runtime-config-resource-vacuum-cost"> for more
d241 1
a241 1
   <member><xref linkend="runtime-config-resource-vacuum-cost"></member>
@


1.37
log
@Patch to mention cost-based delay in vacuum reference

Alvaro Herrera
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.36 2004/12/02 19:28:48 tgl Exp $
d183 1
a183 1
    linkend="runtime" endterm="runtime-config-resource-vacuum-cost"> for more
d241 1
a241 1
   <member><xref linkend="runtime" endterm="runtime-config-resource-vacuum-cost"></member>
@


1.36
log
@Disallow the combination VACUUM FULL FREEZE for safety's sake, for the
reasons I outlined in pghackers a few days ago.

Also, undo someone's overly optimistic decision to reduce tuple state
checks from if (...) elog() to Asserts.  If I trusted this code more,
I might think it was a good idea to disable these checks in production
installations.  But I don't.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.35 2004/03/23 13:21:41 neilc Exp $
d177 9
d241 1
@


1.35
log
@Minor SGML improvements.
@
text
@d2 1
a2 1
$PostgreSQL: pgsql-server/doc/src/sgml/ref/vacuum.sgml,v 1.34 2003/11/29 19:51:39 pgsql Exp $
d23 2
a24 2
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ <replaceable class="PARAMETER">table</replaceable> ]
VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">table</replaceable> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
@


1.34
log
@
$Header: -> $PostgreSQL Changes ...
@
text
@d2 1
a2 1
$PostgreSQL: /cvsroot/pgsql-server/doc/src/sgml/ref/vacuum.sgml,v 1.33 2003/09/12 00:12:47 tgl Exp $
d67 1
a67 1
   <command>FREEZE</command> is a special-purpose option that
d74 1
a74 1
   <command>FREEZE</command> is not recommended for routine use.  Its only
@


1.33
log
@More cleanup of Diagnostics sections.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/vacuum.sgml,v 1.32 2003/08/31 17:32:24 petere Exp $
@


1.32
log
@Add/edit index entries.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/vacuum.sgml,v 1.31 2003/04/26 23:56:51 petere Exp $
d146 1
a146 1
  <title>Diagnostics</title>
d148 5
a152 41
  <variablelist>
   <varlistentry>
    <term><computeroutput>VACUUM</computeroutput></term>
    <listitem>
     <para>
      The command is complete.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><computeroutput>INFO:  --Relation <replaceable class="PARAMETER">table</replaceable>--</computeroutput></term>
    <listitem>
     <para>
      The report header for <replaceable class="PARAMETER">table</replaceable>.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><computeroutput>INFO:  Pages 98: Changed 25, Reapped 74, Empty 0, New 0;
         Tup 1000: Vac 3000, Crash 0, UnUsed 0, MinLen 188, MaxLen 188;
         Re-using: Free/Avail. Space 586952/586952; EndEmpty/Avail. Pages 0/74.
         Elapsed 0/0 sec.</computeroutput></term>
    <listitem>
     <para>
      The analysis for <replaceable class="PARAMETER">table</replaceable> itself.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><computeroutput>INFO:  Index <replaceable class="PARAMETER">index</replaceable>: Pages 28;
         Tuples 1000: Deleted 3000. Elapsed 0/0 sec.</computeroutput></term>
    <listitem>
     <para>
      The analysis for an index on the target table.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
d183 2
a184 2
   The following is an example from running <command>VACUUM</command> on a table
   in the regression database:
d187 27
a213 15
=> VACUUM VERBOSE ANALYZE onek;
INFO:  --Relation onek--
INFO:  Index onek_unique1: Pages 14; Tuples 1000: Deleted 3000.
        CPU 0.00s/0.11u sec elapsed 0.12 sec.
INFO:  Index onek_unique2: Pages 16; Tuples 1000: Deleted 3000.
        CPU 0.00s/0.10u sec elapsed 0.10 sec.
INFO:  Index onek_hundred: Pages 13; Tuples 1000: Deleted 3000.
        CPU 0.00s/0.10u sec elapsed 0.10 sec.
INFO:  Index onek_stringu1: Pages 31; Tuples 1000: Deleted 3000.
        CPU 0.01s/0.09u sec elapsed 0.10 sec.
INFO:  Removed 3000 tuples in 70 pages.
        CPU 0.02s/0.04u sec elapsed 0.07 sec.
INFO:  Pages 94: Changed 0, Empty 0; Tup 1000: Vac 3000, Keep 0, UnUsed 0.
        Total CPU 0.05s/0.45u sec elapsed 0.59 sec.
INFO:  Analyzing onek
@


1.31
log
@Editing of more reference pages.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/vacuum.sgml,v 1.30 2003/03/25 16:15:44 petere Exp $
d16 4
@


1.31.2.1
log
@Update this branch to match CVS head, includes WIN32 improvements.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/vacuum.sgml,v 1.32 2003/08/31 17:32:24 petere Exp $
a15 4

 <indexterm zone="sql-vacuum">
  <primary>VACUUM</primary>
 </indexterm>
@


1.30
log
@Merge documentation into one book.  (Build with "make html".)  Replace
vague cross-references with real links.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/vacuum.sgml,v 1.29 2003/02/19 04:06:28 momjian Exp $
d11 1
d13 2
a14 6
  <refname>
   VACUUM
  </refname>
  <refpurpose>
   garbage-collect and optionally analyze a database
  </refpurpose>
d16 1
d18 1
a18 4
  <refsynopsisdivinfo>
   <date>2001-08-26</date>
  </refsynopsisdivinfo>
  <synopsis>
d21 2
a22 9
  </synopsis>

  <refsect2 id="R2-SQL-VACUUM-1">
   <refsect2info>
    <date>2001-07-10</date>
   </refsect2info>
   <title>
    Inputs
   </title>
d24 2
a25 65
   <para>
    <variablelist>
     <varlistentry>
      <term>FULL</term>
      <listitem>
       <para>
        Selects <quote>full</quote> vacuum, which may reclaim more space,
	but takes much longer and exclusively locks the table.
       </para>
      </listitem>
     </varlistentry>
     <varlistentry>
      <term>FREEZE</term>
      <listitem>
       <para>
        Selects aggressive <quote>freezing</quote> of tuples.
       </para>
      </listitem>
     </varlistentry>
     <varlistentry>
      <term>VERBOSE</term>
      <listitem>
       <para>
	Prints a detailed vacuum activity report for each table.
       </para>
      </listitem>
     </varlistentry>
     <varlistentry>
      <term>ANALYZE</term>
      <listitem>
       <para>
	Updates statistics used by the optimizer to
	determine the most efficient way to execute a query.
       </para>
      </listitem>
     </varlistentry>
     <varlistentry>
      <term><replaceable class="PARAMETER">table</replaceable></term>
      <listitem>
       <para>
	The name (optionally schema-qualified) of a specific table to
	vacuum. Defaults to all tables in the current database.
       </para>
      </listitem>
     </varlistentry>
     <varlistentry>
      <term><replaceable class="PARAMETER">column</replaceable></term>
      <listitem>
       <para>
	The name of a specific column to analyze. Defaults to all columns.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>
  </refsect2>

  <refsect2 id="R2-SQL-VACUUM-2">
   <refsect2info>
    <date>1998-10-04</date>
   </refsect2info>
   <title>
    Outputs
   </title>
   <para>
a26 60
    <variablelist>
     <varlistentry>
      <term><computeroutput>
<returnvalue>VACUUM</returnvalue>
       </computeroutput></term>
      <listitem>
       <para>
	The command is complete.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><computeroutput>
INFO:  --Relation <replaceable class="PARAMETER">table</replaceable>--
       </computeroutput></term>
      <listitem>
       <para>
	The report header for <replaceable class="PARAMETER">table</replaceable>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><computeroutput>
INFO:  Pages 98: Changed 25, Reapped 74, Empty 0, New 0;
         Tup 1000: Vac 3000, Crash 0, UnUsed 0, MinLen 188, MaxLen 188;
         Re-using: Free/Avail. Space 586952/586952; EndEmpty/Avail. Pages 0/74.
         Elapsed 0/0 sec.
       </computeroutput></term>
      <listitem>
       <para>
	The analysis for <replaceable class="PARAMETER">table</replaceable> itself.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><computeroutput>
INFO:  Index <replaceable class="PARAMETER">index</replaceable>: Pages 28;
         Tuples 1000: Deleted 3000. Elapsed 0/0 sec.
       </computeroutput></term>
      <listitem>
       <para>
	The analysis for an index on the target table.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>
  </refsect2>
 </refsynopsisdiv>

 <refsect1 id="R1-SQL-VACUUM-1">
  <refsect1info>
   <date>2001-07-10</date>
  </refsect1info>
  <title>
   Description
  </title>
d30 1
a30 1
   are deleted or obsoleted by UPDATE are not physically removed from
d69 1
a69 1
   database is left un-vacuumed.
d76 4
d81 108
a188 7
  <refsect2 id="R2-SQL-VACUUM-3">
   <refsect2info>
    <date>2001-07-10</date>
   </refsect2info>
   <title>
    Notes
   </title>
d192 1
a192 1
    <command>VACUUM</command>-ed frequently (at least nightly), in order to
d194 1
a194 1
    of records, it may be a good idea to issue a <command>VACUUM
d198 2
a199 2
    <productname>PostgreSQL</productname> query optimizer to make better
    choices in planning user queries.
d209 1
d211 2
a212 2
  </refsect2>
 </refsect1>
a213 4
 <refsect1 id="R1-SQL-VACUUM-2">
  <title>
   Usage
  </title>
d218 2
a219 2
   <programlisting>
regression=> VACUUM VERBOSE ANALYZE onek;
d235 1
a235 1
   </programlisting>
d239 6
a244 16
 <refsect1 id="R1-SQL-VACUUM-3">
  <title>
   Compatibility
  </title>

  <refsect2 id="R2-SQL-VACUUM-4">
   <refsect2info>
    <date>1998-10-04</date>
   </refsect2info>
   <title>
    SQL92
   </title>
   <para>
    There is no <command>VACUUM</command> statement in <acronym>SQL92</acronym>.
   </para>
  </refsect2>
@


1.29
log
@This patch makes the following changes to the documentation:

- more work from the SGML police

- some grammar improvements: rewriting a paragraph or two, replacing
contractions where (IMHO) appropriate

- fix missing utility commands in lock mode docs

- improve CLUSTER, REINDEX, SET SESSION AUTHORIZATION ref pages

Neil Conway
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/vacuum.sgml,v 1.28 2003/01/19 00:13:31 momjian Exp $
d209 1
a209 1
   See the &cite-admin; for details.
@


1.28
log
@This patch includes a lot of minor cleanups to the SGML documentation,
including:

- replacing all the appropriate usages of <citetitle>PostgreSQL
...</citetitle> with &cite-user;, &cite-admin;, and so on

- fix an omission in the EXECUTE documentation

- add some more text to the EXPLAIN documentation

- improve the PL/PgSQL RETURN NEXT documentation (more work to do here)

- minor markup fixes


Neil Conway
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/vacuum.sgml,v 1.27 2002/10/09 16:27:48 momjian Exp $
d288 8
@


1.27
log
@set.patch updates an example in ref/set.sgml to have microsecond
precision.

vacuum.patch updates ref/vacuum.sgml to explicitly state that an
exclusive lock is not obtained during normal (non-FULL) vacuum.

  Rod Taylor
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/vacuum.sgml,v 1.26 2002/09/21 18:32:54 petere Exp $
d209 1
a209 1
   See the <citetitle>Administrator's Guide</> for details.
@


1.26
log
@Add more appropriate markup.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql-server/doc/src/sgml/ref/vacuum.sgml,v 1.25 2002/04/23 02:07:16 tgl Exp $
d189 2
a190 1
   with normal reading and writing of the table.  <command>VACUUM
@


1.25
log
@Update SQL-command reference pages for schema features.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.24 2002/04/21 19:02:39 thomas Exp $
d165 1
a165 1
   are DELETEd or obsoleted by UPDATE are not physically removed from
@


1.24
log
@Augment the date/time examples in the User's Guide to reflect the newer
 capabilities of specifying time zones as intervals per SQL9x.
Put refentrytitle contents on the same line as the tag.
 Otherwise, leading whitespace is propagated into the product, which
 (at least) messes up the ToC layout.
Remove (some) docinfo tags containing dates. Best to omit if the dates
 are not accurate; maybe use CVS dates instead or leave them out.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.23 2002/03/06 06:48:05 momjian Exp $
d76 2
a77 2
	The name of a specific table to vacuum. Defaults to all tables
	in the current database.
@


1.23
log
@Update reference pages for new INFO, NOTICE, WARNING elog() levels.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.22 2001/12/08 03:24:39 thomas Exp $
d8 1
a8 3
  <refentrytitle id="sql-vacuum-title">
   VACUUM
  </refentrytitle>
@


1.22
log
@Use PostgreSQL consistantly throughout docs. Before, usage was split evenly
 between Postgres and PostgreSQL.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.21 2001/11/18 22:17:30 tgl Exp $
d118 1
a118 1
NOTICE:  --Relation <replaceable class="PARAMETER">table</replaceable>--
d129 1
a129 1
NOTICE:  Pages 98: Changed 25, Reapped 74, Empty 0, New 0;
d143 1
a143 1
NOTICE:  Index <replaceable class="PARAMETER">index</replaceable>: Pages 28;
d254 2
a255 2
NOTICE:  --Relation onek--
NOTICE:  Index onek_unique1: Pages 14; Tuples 1000: Deleted 3000.
d257 1
a257 1
NOTICE:  Index onek_unique2: Pages 16; Tuples 1000: Deleted 3000.
d259 1
a259 1
NOTICE:  Index onek_hundred: Pages 13; Tuples 1000: Deleted 3000.
d261 1
a261 1
NOTICE:  Index onek_stringu1: Pages 31; Tuples 1000: Deleted 3000.
d263 1
a263 1
NOTICE:  Removed 3000 tuples in 70 pages.
d265 1
a265 1
NOTICE:  Pages 94: Changed 0, Empty 0; Tup 1000: Vac 3000, Keep 0, UnUsed 0.
d267 1
a267 1
NOTICE:  Analyzing onek
@


1.21
log
@Update various obsolete remarks about VACUUM.
@
text
@d2 2
a3 2
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.20 2001/10/12 23:34:30 momjian Exp $
Postgres documentation
d166 1
a166 1
   In normal <productname>Postgres</productname> operation, tuples that
d229 1
a229 1
    <productname>Postgres</productname> query optimizer to make better
@


1.20
log
@More uppercasing.
@
text
@d2 1
a2 1
$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.19 2001/09/03 12:57:50 petere Exp $
d210 1
a210 2
   See <xref linkend="sql-createdatabase" endterm="sql-createdatabase-title">
   for details.
d224 1
a224 2
    remove expired rows. After copying a large table into
    <productname>Postgres</productname> or after deleting a large number
d255 13
a267 13
NOTICE:  Pages 98: Changed 25, Reapped 74, Empty 0, New 0;
         Tup 1000: Vac 3000, Crash 0, UnUsed 0, MinLen 188, MaxLen 188;
         Re-using: Free/Avail. Space 586952/586952; EndEmpty/Avail. Pages 0/74.
         Elapsed 0/0 sec.
NOTICE:  Index onek_stringu1: Pages 28; Tuples 1000: Deleted 3000. Elapsed 0/0 sec.
NOTICE:  Index onek_hundred: Pages 12; Tuples 1000: Deleted 3000. Elapsed 0/0 sec.
NOTICE:  Index onek_unique2: Pages 19; Tuples 1000: Deleted 3000. Elapsed 0/0 sec.
NOTICE:  Index onek_unique1: Pages 17; Tuples 1000: Deleted 3000. Elapsed 0/0 sec.
NOTICE:  Rel onek: Pages: 98 --> 25; Tuple(s) moved: 1000. Elapsed 0/1 sec.
NOTICE:  Index onek_stringu1: Pages 28; Tuples 1000: Deleted 1000. Elapsed 0/0 sec.
NOTICE:  Index onek_hundred: Pages 12; Tuples 1000: Deleted 1000. Elapsed 0/0 sec.
NOTICE:  Index onek_unique2: Pages 19; Tuples 1000: Deleted 1000. Elapsed 0/0 sec.
NOTICE:  Index onek_unique1: Pages 17; Tuples 1000: Deleted 1000. Elapsed 0/0 sec.
@


1.19
log
@Put some kind of grammatical uniformity in the <refpurpose> lines.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.18 2001/08/26 16:55:59 tgl Exp $
d255 1
a255 1
regression=> vacuum verbose analyze onek;
@


1.18
log
@Transaction IDs wrap around, per my proposal of 13-Aug-01.  More
documentation to come, but the code is all here.  initdb forced.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.17 2001/07/10 22:09:28 tgl Exp $
d18 1
a18 1
   Clean and optionally analyze a <productname>Postgres</productname> database
@


1.17
log
@Changes from Vince Vielhaber to allow the optional clauses of CREATE
USER and ALTER USER to appear in any order, not only the fixed order
they used to be required to appear in.
Also, some changes from Tom Lane to create a FULL option for VACUUM;
it doesn't do anything yet, but I needed to change many of the same
files to make that happen, so now seemed like a good time.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.16 2001/05/25 15:45:31 momjian Exp $
d23 1
a23 1
   <date>2001-07-10</date>
d26 2
a27 2
VACUUM [ FULL ] [ VERBOSE ] [ <replaceable class="PARAMETER">table</replaceable> ]
VACUUM [ FULL ] [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">table</replaceable> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
d50 8
d180 10
a189 1
   Plain <command>VACUUM</command> simply reclaims space and makes it
d194 2
a195 2
   blocks.  This is much slower and requires an exclusive lock on each table
   while it is being processed.
d199 13
a211 5
   <command>VACUUM ANALYZE</command> performs a <command>VACUUM</command>
   and then an <command>ANALYZE</command> for each selected table.  This
   is a handy combination form for routine maintenance scripts.  See
   <xref linkend="sql-analyze" endterm="sql-analyze-title">
   for more details about its processing.
@


1.16
log
@Oops, only wanted python change in the last commit.  Backing out.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.14 2001/05/07 00:43:15 tgl Exp $
d23 1
a23 1
   <date>2001-05-04</date>
d26 2
a27 2
VACUUM [ VERBOSE ] [ <replaceable class="PARAMETER">table</replaceable> ]
VACUUM [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">table</replaceable> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
d32 1
a32 1
    <date>1998-10-04</date>
d41 9
d70 2
a71 1
	The name of a specific table to vacuum. Defaults to all tables.
d151 1
a151 1
   <date>1998-10-04</date>
d172 10
d191 1
a191 1
    <date>1998-10-04</date>
d199 2
a200 2
    <command>VACUUM</command>-ed nightly, in order to remove
    expired rows. After copying a large table into
d208 8
@


1.15
log
@While changing Cygwin Python to build its core as a DLL (like Win32
Python) to support shared extension modules, I have learned that Guido
prefers the style of the attached patch to solve the above problem.
I feel that this solution is particularly appropriate in this case
because the following:

    PglargeType
    PgType
    PgQueryType

are already being handled in the way that I am proposing for PgSourceType.

Jason Tishler
@
text
@d157 1
a157 2
   current database. It also detects any extraneous files in the
   database directory.  With a parameter, <command>VACUUM</command> processes
@


1.14
log
@Rewrite of planner statistics-gathering code.  ANALYZE is now available as
a separate statement (though it can still be invoked as part of VACUUM, too).
pg_statistic redesigned to be more flexible about what statistics are
stored.  ANALYZE now collects a list of several of the most common values,
not just one, plus a histogram (not just the min and max values).  Random
sampling is used to make the process reasonably fast even on very large
tables.  The number of values and histogram bins collected is now
user-settable via an ALTER TABLE command.

There is more still to do; the new stats are not being used everywhere
they could be in the planner.  But the remaining changes for this project
should be localized, and the behavior is already better than before.

A not-very-related change is that sorting now makes use of btree comparison
routines if it can find one, rather than invoking '<' twice.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.13 2001/01/13 23:58:55 petere Exp $
d157 2
a158 1
   current database.  With a parameter, <command>VACUUM</command> processes
@


1.13
log
@Terminology cleanup: class -> table, instance -> row, attribute -> column,
etc.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.12 2000/10/05 19:57:23 momjian Exp $
d18 1
a18 1
   Clean and analyze a <productname>Postgres</productname> database
d23 1
a23 1
   <date>1999-07-20</date>
d26 1
a26 1
VACUUM [ VERBOSE ] [ ANALYZE ] [ <replaceable class="PARAMETER">table</replaceable> ]
d52 1
a52 1
	Updates column statistics used by the optimizer to
d93 1
a93 1
	The command has been accepted and the database is being cleaned.
d147 6
a152 3
   <command>VACUUM</command> serves two purposes in 
   <productname>Postgres</productname> as both a means to reclaim storage and
   also a means to collect information for the optimizer.
d156 3
a158 11
   <command>VACUUM</command> opens every table in the database,
   cleans out records from rolled back transactions, and updates statistics in the
   system catalogs.  The statistics maintained include the number of
   tuples and number of pages stored in all tables.
  </para>


  <para>
   <command>VACUUM ANALYZE</command> collects statistics representing the
   dispersion of the data in each column.
   This information is valuable when several query execution paths are possible.
d162 5
a166 2
   Running <command>VACUUM</command>
   periodically will increase the speed of the database in processing user queries.
d176 1
a176 3
   <para>
    The open database is the target for <command>VACUUM</command>.
   </para>
d183 2
a184 1
    ANALYZE</command> query. This will update the system catalogs with
@


1.12
log
@Final proofreader changes to docs.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.11 2000/10/05 19:48:19 momjian Exp $
d153 1
a153 1
   <command>VACUUM</command> opens every class in the database,
d156 1
a156 1
   tuples and number of pages stored in all classes.
d184 1
a184 1
    expired rows. After copying a large class into
@


1.11
log
@Add proofreader's changes to docs.
Fix misspelling of disbursion to dispersion.
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.10 2000/09/12 21:12:45 momjian Exp $
d183 1
a183 1
    <command>VACUUM</command>-ed nightly, in order to keep remove
@


1.10
log
@typo fix
@
text
@d2 1
a2 1
$Header: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.9 2000/04/14 17:37:54 momjian Exp $
d162 1
a162 1
   disbursion of the data in each column.
@


1.9
log
@UPdate vacuum man page to be clearer.
@
text
@d2 1
a2 1
$Header: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.8 2000/04/05 21:51:11 momjian Exp $
d183 1
a183 1
    <command>VACUUMM</command>-ed nightly, in order to keep remove
@


1.8
log
@Update vacuum to mention analyze
@
text
@d2 1
a2 1
$Header: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.7 1999/12/07 22:41:41 momjian Exp $
d182 9
a190 9
    We recommend that active production databases be cleaned nightly, in order
    to keep statistics relatively current.  The <command>VACUUM</command>
    query may be executed at any time, however.  In particular, after
    copying a large class into <productname>Postgres</productname> 
    or after deleting a large number of
    records, it may be a good idea to issue a <command>VACUUM ANALYZE</command>
    query.  This will update the system catalogs with the results of all
    recent changes, and allow the <productname>Postgres</productname> 
    query optimizer to make better choices in planning user queries.
@


1.7
log
@Okay, that should put us back in sync. These two patches (src & doc) are
against the sources from one hour ago and contain all the portable and
up
to date stuff.

A few other CVS "householding" things you might want to take care of:

* Remove the src/bin/cleardbdir directory

* Remove the file src/bin/psql/sql_help.h from the repository, as it is
a derived file and is build by the release_prep.

Peter Eisentraut
@
text
@d2 1
a2 1
$Header: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.6 1999/11/28 02:17:04 tgl Exp $
a53 2
	The statistics represent the disbursion of the data in each column.
	This information is valuable when several execution paths are possible.
d159 7
d187 1
a187 1
    records, it may be a good idea to issue a <command>VACUUM</command>
d192 1
@


1.6
log
@Remove obsolete note about pg_vlock lock file.
@
text
@d2 1
a2 1
$Header: /usr/local/cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.5 1999/07/22 15:09:15 thomas Exp $
d27 1
a27 1
VACUUM [ VERBOSE ] ANALYZE [ <replaceable class="PARAMETER">ER">t</replaceable>BLE> [ (<replaceable class="PARAMETER">column</replaceable> [, ...] ) ] ]
@


1.5
log
@Complete merge of all old man page information.
ecpg reference page still needs formatting.
@
text
@d2 1
a2 1
$Header$
a185 10
   </para>
   <para>
    If the server crashes during a <command>VACUUM</command> command, 
    chances are it will leave a lock file hanging around.  
    Attempts to re-run the <command>VACUUM</command> command
    result in an error message about the creation of a lock file.  If you
    are sure <command>VACUUM</command> is not running, 
    remove the <filename>pg_vlock</filename> file in your
    database directory 
    (i.e. <filename><envar>PGDATA</envar>/base/dbname/pg_vlock</filename>).
@


1.4
log
@Complete first pass at markup adjustments for docbook2man man pages.
Add some internal cross references to select.sgml.
@
text
@d1 6
a6 1
<refentry id="SQL-VACUUM-1">
d8 1
a8 1
  <refentrytitle id="vacuum">
d23 1
a23 1
   <date>1998-10-04</date>
d233 1
d242 1
a242 1
    There is no <command>VACUUM</command> statement in SQL92.
@


1.3
log
@Clean up to ensure tag completion as required by the newest versions
 of Norm's Modular Style Sheets and jade/docbook.
From Vince Vielhaber <vev@@michvhf.com>.
@
text
@d1 203
a203 209
<REFENTRY ID="SQL-VACUUM-1">
<REFMETA>
<REFENTRYTITLE id="vacuum">
VACUUM
</REFENTRYTITLE>
<REFMISCINFO>SQL - Language Statements</REFMISCINFO>
</REFMETA>
<REFNAMEDIV>
<REFNAME>
VACUUM
</REFNAME>
<REFPURPOSE>
Clean and analyze a <productname>Postgres</productname> database
</REFPURPOSE>
  </refnamediv>
<REFSYNOPSISDIV>
<REFSYNOPSISDIVINFO>
<DATE>1998-10-04</DATE>
</REFSYNOPSISDIVINFO>
<SYNOPSIS>
VACUUM [ VERBOSE ] [ ANALYZE ] [ <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE> ]
VACUUM [ VERBOSE ] ANALYZE [ <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE> [ (<REPLACEABLE CLASS="PARAMETER">column</REPLACEABLE> [, ...] ) ] ]
</SYNOPSIS>

    <REFSECT2 ID="R2-SQL-VACUUM-1">
      <REFSECT2INFO>
	<DATE>1998-10-04</DATE>
      </REFSECT2INFO>
      <TITLE>
	Inputs
      </TITLE>
      <PARA>
	
	<VARIABLELIST>
	  <VARLISTENTRY>
	    <TERM>
	      VERBOSE
	    </term>
	    <LISTITEM>
	      <PARA>
		Prints a detailed vacuum activity report for each table.
	      </para>
	    </listitem>
	  </varlistentry>
	  <VARLISTENTRY>
	    <TERM>
	      ANALYZE
	    </term>
	    <LISTITEM>
	      <PARA>
		Updates column statistics used by the optimizer to
		determine the most efficient way to execute a query.
		The statistics represent the disbursion of the data in each column.
		This information is valuable when several execution paths are possible.
	      </para>
	    </listitem>
	  </varlistentry>
	  <VARLISTENTRY>
	    <TERM>
	      <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
	    </term>
	    <LISTITEM>
	      <PARA>
		The name of a specific table to vacuum. Defaults to all tables.
	      </para>
	    </listitem>
	  </varlistentry>
	  <VARLISTENTRY>
	    <TERM>
	      <REPLACEABLE CLASS="PARAMETER">column</REPLACEABLE>
	    </term>
	    <LISTITEM>
	      <PARA>
		The name of a specific column to analyze. Defaults to all columns.
	      </para>
	    </listitem>
	  </varlistentry>
	</VARIABLELIST>
      </para>
    </REFSECT2>

    <REFSECT2 ID="R2-SQL-VACUUM-2">
      <REFSECT2INFO>
	<DATE>1998-10-04</DATE>
      </REFSECT2INFO>
      <TITLE>
	Outputs
      </TITLE>
      <PARA>

	<VARIABLELIST>
	  <VARLISTENTRY>
	    <TERM>
	      <ReturnValue>VACUUM</ReturnValue>
	    </TERM>
	    <LISTITEM>
	      <PARA>
		The command has been accepted and the database is being cleaned.
	      </para>
	    </listitem>
	  </varlistentry>
	  
	  <VARLISTENTRY>
	    <TERM>
	      NOTICE:  --Relation <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>--
	    </term>
	    <LISTITEM>
	      <PARA>
		The report header for <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>.
	      </para>
	    </listitem>
	  </varlistentry>

	  <VARLISTENTRY>
	    <TERM>
	      NOTICE:  Pages 98: Changed 25, Reapped 74, Empty 0, New 0;
	      Tup 1000: Vac 3000, Crash 0, UnUsed 0, MinLen 188, MaxLen 188;
	      Re-using: Free/Avail. Space 586952/586952; EndEmpty/Avail. Pages 0/74.
	      Elapsed 0/0 sec.
	    </term>
	    <LISTITEM>
	      <PARA>
		The analysis for <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE> itself.
	      </para>
	    </listitem>
	  </varlistentry>
	  
	  <VARLISTENTRY>
	    <TERM>
	      NOTICE:  Index <REPLACEABLE CLASS="PARAMETER">index</REPLACEABLE>: Pages 28;
	      Tuples 1000: Deleted 3000. Elapsed 0/0 sec.
	    </term>
	    <LISTITEM>
	      <PARA>
		The analysis for an index on the target table.
	      </para>
	    </listitem>
	  </varlistentry>
	</VARIABLELIST>
      </para>
    </REFSECT2>
  </REFSYNOPSISDIV>

  <REFSECT1 ID="R1-SQL-VACUUM-1">
    <REFSECT1INFO>
      <DATE>1998-10-04</DATE>
    </REFSECT1INFO>
    <TITLE>
      Description
    </TITLE>
    <PARA>
      <command>VACUUM</command> serves two purposes in 
      <productname>Postgres</productname> as both a means to reclaim storage and
      also a means to collect information for the optimizer.
    </para>
    <para>
      <command>VACUUM</command> opens every class in the database,
      cleans out records from rolled back transactions, and updates statistics in the
      system catalogs.  The statistics maintained include the number of
      tuples and number of pages stored in all classes.

      Running <command>VACUUM</command>
      periodically will increase the speed of the database in processing user queries.
    </para>

    <REFSECT2 ID="R2-SQL-VACUUM-3">
      <REFSECT2INFO>
	<DATE>1998-10-04</DATE>
      </REFSECT2INFO>
      <TITLE>
	Notes
      </TITLE>
      <PARA>
	The open database is target for <command>VACUUM</command>.
      </para>
      <para>
	We recommend that active production databases be cleaned nightly, in order
	to keep statistics relatively current.  The <command>VACUUM</command>
	query may be executed at any time, however.  In particular, after
	copying a large class into <productname>Postgres</productname> 
	or after deleting a large number of
	records, it may be a good idea to issue a <command>VACUUM</command>
	query.  This will update the system catalogs with the results of all
	recent changes, and allow the <productname>Postgres</productname> 
	query optimizer to make better choices in planning user queries.
      </para>
      <para>
	If the server crashes during a <command>VACUUM</command> command, 
	chances are it will leave a lock file hanging around.  
	Attempts to re-run the <command>VACUUM</command> command
	result in an error message about the creation of a lock file.  If you
	are sure <command>VACUUM</command> is not running, 
	remove the <filename>pg_vlock</filename> file in your
	database directory 
	(i.e. <filename><envar>PGDATA</envar>/base/dbname/pg_vlock</filename>).
      </PARA>
      
    </REFSECT2>
  </refsect1>

  <REFSECT1 ID="R1-SQL-VACUUM-2">
    <TITLE>
      Usage
    </TITLE>
    <PARA>
      The following is an example from running <command>VACUUM</command> on a table
      in the regression database:
      
      <ProgramListing>
d220 38
a257 21
      </ProgramListing>
    </para>
  </REFSECT1>

  <REFSECT1 ID="R1-SQL-VACUUM-3">
    <TITLE>
      Compatibility
    </TITLE>
    <REFSECT2 ID="R2-SQL-VACUUM-4">
      <REFSECT2INFO>
	<DATE>1998-10-04</DATE>
      </REFSECT2INFO>
      <TITLE>
	SQL92
      </TITLE>
      <PARA>
	There is no <COMMAND>VACUUM</COMMAND> statement in SQL92.
      </para>
    </refsect2>
  </refsect1>
</REFENTRY>
@


1.2
log
@Add id attribute to reftitle to allow cross referencing from the new
 vaccumdb reference page.
@
text
@d15 1
d25 185
a209 157
<REFSECT2 ID="R2-SQL-VACUUM-1">
<REFSECT2INFO>
<DATE>1998-10-04</DATE>
</REFSECT2INFO>
<TITLE>
Inputs
</TITLE>
<PARA>

<VARIABLELIST>
<VARLISTENTRY>
<TERM>
VERBOSE
<LISTITEM>
<PARA>
Prints a detailed vacuum activity report for each table.

<VARLISTENTRY>
<TERM>
ANALYZE
<LISTITEM>
<PARA>
Updates column statistics used by the optimizer to
determine the most efficient way to execute a query.
The statistics represent the disbursion of the data in each column.
This information is valuable when several execution paths are possible.

<VARLISTENTRY>
<TERM>
<REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>
<LISTITEM>
<PARA>
The name of a specific table to vacuum. Defaults to all tables.

<VARLISTENTRY>
<TERM>
<REPLACEABLE CLASS="PARAMETER">column</REPLACEABLE>
<LISTITEM>
<PARA>
The name of a specific column to analyze. Defaults to all columns.

</VARIABLELIST>

</REFSECT2>

<REFSECT2 ID="R2-SQL-VACUUM-2">
<REFSECT2INFO>
<DATE>1998-10-04</DATE>
</REFSECT2INFO>
<TITLE>
Outputs
</TITLE>
<PARA>

<VARIABLELIST>
<VARLISTENTRY>
<TERM>
<ReturnValue>VACUUM</ReturnValue>
</TERM>
<LISTITEM>
<PARA>
The command has been accepted and the database is being cleaned.

<VARLISTENTRY>
<TERM>
NOTICE:  --Relation <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>--
<LISTITEM>
<PARA>
The report header for <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE>.

<VARLISTENTRY>
<TERM>
NOTICE:  Pages 98: Changed 25, Reapped 74, Empty 0, New 0;
         Tup 1000: Vac 3000, Crash 0, UnUsed 0, MinLen 188, MaxLen 188;
         Re-using: Free/Avail. Space 586952/586952; EndEmpty/Avail. Pages 0/74.
         Elapsed 0/0 sec.
<LISTITEM>
<PARA>
The analysis for <REPLACEABLE CLASS="PARAMETER">table</REPLACEABLE> itself.

<VARLISTENTRY>
<TERM>
NOTICE:  Index <REPLACEABLE CLASS="PARAMETER">index</REPLACEABLE>: Pages 28;
         Tuples 1000: Deleted 3000. Elapsed 0/0 sec.
<LISTITEM>
<PARA>
The analysis for an index on the target table.

</VARIABLELIST>

</REFSECT2>
</REFSYNOPSISDIV>

<REFSECT1 ID="R1-SQL-VACUUM-1">
<REFSECT1INFO>
<DATE>1998-10-04</DATE>
</REFSECT1INFO>
<TITLE>
Description
</TITLE>
<PARA>
<command>VACUUM</command> serves two purposes in 
<productname>Postgres</productname> as both a means to reclaim storage and
also a means to collect information for the optimizer.

<para>
<command>VACUUM</command> opens every class in the database,
cleans out records from rolled back transactions, and updates statistics in the
system catalogs.  The statistics maintained include the number of
tuples and number of pages stored in all classes.

Running <command>VACUUM</command>
periodically will increase the speed of the database in processing user queries.

<REFSECT2 ID="R2-SQL-VACUUM-3">
<REFSECT2INFO>
<DATE>1998-10-04</DATE>
</REFSECT2INFO>
<TITLE>
Notes
</TITLE>
<PARA>
The open database is target for <command>VACUUM</command>.

<para>
We recommend that active production databases be cleaned nightly, in order
to keep statistics relatively current.  The <command>VACUUM</command>
query may be executed at any time, however.  In particular, after
copying a large class into <productname>Postgres</productname> 
or after deleting a large number of
records, it may be a good idea to issue a <command>VACUUM</command>
query.  This will update the system catalogs with the results of all
recent changes, and allow the <productname>Postgres</productname> 
query optimizer to make better choices in planning user queries.

<para>
If the server crashes during a <command>VACUUM</command> command, 
chances are it will leave a lock file hanging around.  
Attempts to re-run the <command>VACUUM</command> command
result in an error message about the creation of a lock file.  If you
are sure <command>VACUUM</command> is not running, 
remove the <filename>pg_vlock</filename> file in your
database directory 
(i.e. <filename><envar>PGDATA</envar>/base/dbname/pg_vlock</filename>).
</PARA>

</REFSECT2>

<REFSECT1 ID="R1-SQL-VACUUM-2">
<TITLE>
Usage
</TITLE>
<PARA>
The following is an example from running <command>VACUUM</command> on a table
in the regression database:

<ProgramListing>
d226 20
a245 20
</ProgramListing>

</REFSECT1>

<REFSECT1 ID="R1-SQL-VACUUM-3">
<TITLE>
Compatibility
</TITLE>
<PARA>

<REFSECT2 ID="R2-SQL-VACUUM-4">
<REFSECT2INFO>
<DATE>1998-10-04</DATE>
</REFSECT2INFO>
<TITLE>
SQL92
</TITLE>
<PARA>
There is no <COMMAND>VACUUM</COMMAND> statement in SQL92.

@


1.1
log
@Add new information for utility commands.
 Haven't yet done cleardbdir, ipcclean, pg_passwd, and pg_upgrade.
Add reference info for the SQL VACUUM command (oops, forgot it earlier).
@
text
@d3 1
a3 1
<REFENTRYTITLE>
@
