database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-12-21 05:21:08 +03:00
Code Activity

Minor documentation updates from Simon Riggs.

Browse Source
This commit is contained in:
Tom Lane
2004-11-04 19:08:42 +00:00
parent e505a70c7f
commit e48b9b5570
3 changed files with 44 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
doc/src/sgml/ref/reindex.sgml
View File

@@ -1,5 +1,5 @@
<!--
$PostgreSQL: pgsql/doc/src/sgml/ref/reindex.sgml,v 1.24 2004/10/24 22:52:04 tgl Exp $
$PostgreSQL: pgsql/doc/src/sgml/ref/reindex.sgml,v 1.25 2004/11/04 19:08:08 tgl Exp $
PostgreSQL documentation
-->
@@ -29,7 +29,7 @@ REINDEX { DATABASE | TABLE | INDEX } <replaceable class="PARAMETER">name</replac
<para>
<command>REINDEX</command> rebuilds an index based on the data
stored in the table, replacing the old copy of the index. There are
stored in the index's table, replacing the old copy of the index. There are
two main reasons to use <command>REINDEX</command>:
<itemizedlist>
@@ -98,6 +98,8 @@ REINDEX { DATABASE | TABLE | INDEX } <replaceable class="PARAMETER">name</replac
<para>
The name of the specific database, table, or index to be
reindexed. Table and index names may be schema-qualified.
Presently, <command>REINDEX DATABASE</> can only reindex the current
database, so its parameter must match the current database's name.
</para>
</listitem>
</varlistentry>
@@ -119,13 +121,7 @@ REINDEX { DATABASE | TABLE | INDEX } <replaceable class="PARAMETER">name</replac
<para>
If you suspect corruption of an index on a user table, you can
simply rebuild that index, or all indexes on the table, using
<command>REINDEX INDEX</command> or <command>REINDEX
TABLE</command>. Another approach to dealing with a corrupted
user-table index is just to drop and recreate it. This may in fact
be preferable if you would like to maintain some semblance of
normal operation on the table meanwhile. <command>REINDEX</>
acquires exclusive lock on the table, while <command>CREATE
INDEX</> only locks out writes not reads of the table.
<command>REINDEX INDEX</command> or <command>REINDEX TABLE</command>.
</para>
<para>
@@ -187,6 +183,22 @@ REINDEX { DATABASE | TABLE | INDEX } <replaceable class="PARAMETER">name</replac
a btree</> errors.)
</para>
<para>
<command>REINDEX</command> is similar to a drop and recreate of the index
in that the index contents are rebuilt from scratch. However, the locking
considerations are rather different. <command>REINDEX</> locks out writes
but not reads of the index's parent table. It also takes an exclusive lock
on the specific index being processed, which will block reads that attempt
to use that index. In contrast, <command>DROP INDEX</> momentarily takes
exclusive lock on the parent table, blocking both writes and reads. The
subsequent <command>CREATE INDEX</> locks out writes but not reads; since
the index is not there, no read will attempt to use it, meaning that there
will be no blocking but reads may be forced into expensive sequential
scans. Another important point is that the drop/create approach
invalidates any cached query plans that use the index, while
<command>REINDEX</> does not.
</para>
<para>
Prior to <productname>PostgreSQL</productname> 7.4, <command>REINDEX
TABLE</> did not automatically process TOAST tables, and so those had