REINDEX 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 REINDEX:
The name of the specific database, table, or index to be
reindexed. Table and index names may be schema-qualified.
+ Presently, REINDEX DATABASE can only reindex the current
+ database, so its parameter must match the current database's name.
If you suspect corruption of an index on a user table, you can
simply rebuild that index, or all indexes on the table, using
- REINDEX INDEX or REINDEX
- TABLE. 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. REINDEX
- acquires exclusive lock on the table, while CREATE
- INDEX only locks out writes not reads of the table.
+ REINDEX INDEX or REINDEX TABLE.
a btree errors.)
+ REINDEX 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. 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, DROP INDEX momentarily takes
+ exclusive lock on the parent table, blocking both writes and reads. The
+ subsequent 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
+ REINDEX does not.
+
+
Prior to
PostgreSQL 7.4,
REINDEX TABLE did not automatically process TOAST tables, and so those had
Specifies the main server configuration file
- (customarily called postgresql.conf).
+ (customarily called postgresql.conf).
This option can only be set on the postmaster command line.
Specifies that the
postmaster should create an- additional process-id (PID) file for use by server administration
- programs.
+ additional process-id (PID) file for use by server administration
+ programs.
This option can only be set at server start.
Sets the planner's assumption about the effective size of the
- disk cache (that is, the portion of the kernel's disk cache
- that will be used for
PostgreSQL- data files). This is measured in disk pages, which are
+ disk cache that is available to a single index scan. This is
+ factored into estimates of the cost of using an index; a higher
+ value makes it more likely index scans will be used, a lower
+ value makes it more likely sequential scans will be used. When
+ setting this parameter you should consider both
+
PostgreSQL's shared buffers and the
+ portion of the kernel's disk cache that will be used for
+
PostgreSQL data files. Also, take into
+ account the expected number of concurrent queries using different
+ indexes, since they will have to share the available space.
+ This parameter has no effect on the size of shared memory
+ allocated by PostgreSQL, nor does it reserve kernel disk cache;
+ it is used only for estimation purposes.
+ The value is measured in disk pages, which are
normally 8192 bytes each. The default is 1000.
random_page_cost (floating point)
- Sets the query planner's estimate of the cost of a
+ Sets the planner's estimate of the cost of a
nonsequentially fetched disk page. This is measured as a
multiple of the cost of a sequential page fetch. A higher
value makes it more likely a sequential scan will be used, a
cpu_tuple_cost (floating point)
- Sets the query planner's estimate of the cost of processing
+ Sets the planner's estimate of the cost of processing
each row during a query. This is measured as a fraction of
the cost of a sequential page fetch. The default is 0.01.
cpu_index_tuple_cost (floating point)
- Sets the query planner's estimate of the cost of processing
+ Sets the planner's estimate of the cost of processing
each index row during an index scan. This is measured as a
fraction of the cost of a sequential page fetch. The default
is 0.001.
* Written by Peter Eisentraut
. *
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/utils/misc/guc.c,v 1.246 2004/10/22 19:48:19 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/utils/misc/guc.c,v 1.247 2004/11/04 19:08:42 tgl Exp $
*
*--------------------------------------------------------------------
*/
"pages, which are normally 8 kB each.")
},
&effective_cache_size,
- DEFAULT_EFFECTIVE_CACHE_SIZE, 0, DBL_MAX, NULL, NULL
+ DEFAULT_EFFECTIVE_CACHE_SIZE, 1, DBL_MAX, NULL, NULL
},
{
{"random_page_cost", PGC_USERSET, QUERY_TUNING_COST,
projects / postgresql.git / commitdiff