-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.18 2001/11/12 19:19:39 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.19 2001/11/18 22:17:30 tgl Exp $ -->
<chapter id="backup">
<title>Backup and Restore</title>
running will not be in the dump. <application>pg_dump</> does not
block other operations on the database while it is working.
(Exceptions are those operations that need to operate with an
- exclusive lock, such as <command>VACUUM</command>.)
+ exclusive lock, such as <command>VACUUM FULL</command>.)
</para>
<important>
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.6 2001/11/12 19:19:39 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.7 2001/11/18 22:17:30 tgl Exp $
-->
<chapter id="maintenance">
In normal <productname>PostgreSQL</productname> operation, an UPDATE or
DELETE of a row does not immediately remove the old <firstterm>tuple</>
(version of the row). This approach is necessary to gain the benefits
- of multiversion concurrency control (see the User's Guide): the tuple
- must not be deleted while
+ of multiversion concurrency control (see the <citetitle>User's Guide</>):
+ the tuple must not be deleted while
it is still potentially visible to other transactions. But eventually,
an outdated or deleted tuple is no longer of interest to any transaction.
The space it occupies must be reclaimed for reuse by new tuples, to avoid
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/analyze.sgml,v 1.3 2001/10/16 01:13:44 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/analyze.sgml,v 1.4 2001/11/18 22:17:30 tgl Exp $
Postgres documentation
-->
just after making major changes in the contents of a table. Accurate
statistics will help the planner to choose the most appropriate query
plan, and thereby improve the speed of query processing. A common
- strategy is to run <command>VACUUM</command> and <command>ANALYZE</command>
- once a day during a low-usage time of day.
+ strategy is to run <xref linkend="sql-vacuum" endterm="sql-vacuum-title">
+ and <command>ANALYZE</command> once a day during a low-usage time of day.
</para>
<para>
- Unlike <xref linkend="sql-vacuum" endterm="sql-vacuum-title">,
+ Unlike <command>VACUUM FULL</command>,
<command>ANALYZE</command> requires
only a read lock on the target table, so it can run in parallel with
other activity on the table.
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.20 2001/10/12 23:34:30 momjian Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/vacuum.sgml,v 1.21 2001/11/18 22:17:30 tgl Exp $
Postgres documentation
-->
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="sql-createdatabase" endterm="sql-createdatabase-title">
- for details.
+ See the <citetitle>Administrator's Guide</> for details.
</para>
<refsect2 id="R2-SQL-VACUUM-3">
<para>
We recommend that active production databases be
<command>VACUUM</command>-ed frequently (at least nightly), in order to
- remove expired rows. After copying a large table into
- <productname>Postgres</productname> or after deleting a large number
+ remove expired rows. After adding or deleting a large number
of records, it may be a good idea to issue a <command>VACUUM
ANALYZE</command> command for the affected table. This will update the
system catalogs with
<programlisting>
regression=> VACUUM VERBOSE ANALYZE onek;
NOTICE: --Relation onek--
-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.
+NOTICE: Index onek_unique1: Pages 14; Tuples 1000: Deleted 3000.
+ CPU 0.00s/0.11u sec elapsed 0.12 sec.
+NOTICE: Index onek_unique2: Pages 16; Tuples 1000: Deleted 3000.
+ CPU 0.00s/0.10u sec elapsed 0.10 sec.
+NOTICE: Index onek_hundred: Pages 13; Tuples 1000: Deleted 3000.
+ CPU 0.00s/0.10u sec elapsed 0.10 sec.
+NOTICE: Index onek_stringu1: Pages 31; Tuples 1000: Deleted 3000.
+ CPU 0.01s/0.09u sec elapsed 0.10 sec.
+NOTICE: Removed 3000 tuples in 70 pages.
+ CPU 0.02s/0.04u sec elapsed 0.07 sec.
+NOTICE: 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.
+NOTICE: Analyzing onek
VACUUM
</programlisting>
</para>
projects / postgresql / commitdiff