Change "indices" to "indexes", per OED.
This commit is contained in:
Peter Eisentraut
parent
f000ffd28e
commit
a6677f0f9e
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.13 2000/12/26 00:10:37 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.14 2001/05/17 21:50:15 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="overview">
|
||||
@ -603,7 +603,7 @@ current context are performed.
|
||||
|
||||
<para>
|
||||
The planner/optimizer decides which plans should be generated
|
||||
based upon the types of indices defined on the relations appearing in
|
||||
based upon the types of indexes defined on the relations appearing in
|
||||
a query. There is always the possibility of performing a
|
||||
sequential scan on a relation, so a plan using only
|
||||
sequential scans is always created. Assume an index is defined on a
|
||||
@ -612,7 +612,7 @@ current context are performed.
|
||||
<literal>relation.attribute OPR constant</literal>. If
|
||||
<literal>relation.attribute</literal> happens to match the key of the B-tree
|
||||
index and <literal>OPR</literal> is anything but '<>' another plan is created using
|
||||
the B-tree index to scan the relation. If there are further indices
|
||||
the B-tree index to scan the relation. If there are further indexes
|
||||
present and the restrictions in the query happen to match a key of an
|
||||
index further plans will be considered.
|
||||
</para>
|
||||
@ -889,7 +889,7 @@ The {\tt AGG} node is followed by a {\tt GRP} node. The implementation
|
||||
of the {\it grouping} logic needs a sorted table for its operation so
|
||||
the {\tt GRP} node is followed by a {\tt SORT} node. The {\tt SORT}
|
||||
operation gets its tuples from a kind of {\tt Scan} node (if no
|
||||
indices are present this will be a simple {\tt SeqScan} node). Any
|
||||
indexes are present this will be a simple {\tt SeqScan} node). Any
|
||||
qualifications present are attached to the {\tt Scan} node. Figure
|
||||
\ref{plan_having} shows the {\it plan} created for the query given in
|
||||
example \ref{having}.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.8 2001/05/17 21:12:48 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.9 2001/05/17 21:50:15 petere Exp $ -->
|
||||
<chapter id="backup">
|
||||
<title>Backup and Restore</title>
|
||||
|
||||
@ -355,7 +355,7 @@ tar -cf backup.tar /usr/local/pgsql/data
|
||||
Also note that the file system backup will not necessarily be
|
||||
smaller than an SQL dump. On the contrary, it will most likely be
|
||||
larger. (<application>pg_dump</application> does not need to dump
|
||||
the contents of indices for example, just the commands to recreate
|
||||
the contents of indexes for example, just the commands to recreate
|
||||
them.)
|
||||
</para>
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.10 2001/05/17 21:50:15 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="extend">
|
||||
@ -96,7 +96,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 peter
|
||||
file that stores all rows of a table) but the
|
||||
user can "look inside" at the attributes of these types
|
||||
from the query language and optimize their retrieval by
|
||||
(for example) defining indices on the attributes.
|
||||
(for example) defining indexes on the attributes.
|
||||
<productname>Postgres</productname> base types are further
|
||||
divided into built-in
|
||||
types and user-defined types. Built-in types (like
|
||||
@ -149,7 +149,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 peter
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_index</entry>
|
||||
<entry> secondary indices</entry>
|
||||
<entry> secondary indexes</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>pg_proc</entry>
|
||||
@ -256,7 +256,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 peter
|
||||
pg_am, pg_amop, pg_amproc, pg_operator and
|
||||
pg_opclass are particularly hard to understand
|
||||
and will be described in depth (in the section
|
||||
on interfacing types and operators to indices)
|
||||
on interfacing types and operators to indexes)
|
||||
after we have discussed basic extensions.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.16 2001/04/20 15:52:33 thomas Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.17 2001/05/17 21:50:15 petere Exp $
|
||||
Genetic Optimizer
|
||||
-->
|
||||
|
||||
@ -51,8 +51,8 @@ Genetic Optimizer
|
||||
<firstterm>join methods</firstterm>
|
||||
(e.g., nested loop, hash join, merge join in <productname>Postgres</productname>) to
|
||||
process individual <command>join</command>s and a diversity of
|
||||
<firstterm>indices</firstterm> (e.g., r-tree,
|
||||
b-tree, hash in <productname>Postgres</productname>) as access paths for relations.
|
||||
<firstterm>indexes</firstterm> (e.g., R-tree,
|
||||
B-tree, hash in <productname>Postgres</productname>) as access paths for relations.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
</AuthorGroup>
|
||||
<Date>Transcribed 1998-02-19</Date>
|
||||
</DocInfo>
|
||||
<Title>GiST Indices</Title>
|
||||
<Title>GiST Indexes</Title>
|
||||
|
||||
<Para>
|
||||
The information about GIST is at
|
||||
|
||||
@ -1,27 +1,22 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.16 2001/05/12 22:51:34 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.17 2001/05/17 21:50:16 petere Exp $ -->
|
||||
|
||||
<chapter id="indices">
|
||||
<title id="indices-title">Indices</title>
|
||||
<chapter id="indexes">
|
||||
<title id="indexes-title">Indices</title>
|
||||
|
||||
<indexterm zone="indices">
|
||||
<primary>indices</primary>
|
||||
</indexterm>
|
||||
|
||||
<indexterm>
|
||||
<indexterm zone="indexes">
|
||||
<primary>indexes</primary>
|
||||
<see>indices</see>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
Indices are a common way to enhance database performance. An index
|
||||
Indexes are a common way to enhance database performance. An index
|
||||
allows the database server to find and retrieve specific rows much
|
||||
faster than it could do without an index. But indices also add
|
||||
faster than it could do without an index. But indexes also add
|
||||
overhead to the database system as a whole, so they should be used
|
||||
sensibly.
|
||||
</para>
|
||||
|
||||
|
||||
<sect1 id="indices-intro">
|
||||
<sect1 id="indexes-intro">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
@ -73,7 +68,7 @@ CREATE INDEX test1_id_index ON test1 (id);
|
||||
|
||||
<para>
|
||||
To remove an index, use the <command>DROP INDEX</command> command.
|
||||
Indices can be added and removed from tables at any time.
|
||||
Indexes can be added and removed from tables at any time.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -88,10 +83,10 @@ CREATE INDEX test1_id_index ON test1 (id);
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Indices can also benefit <command>UPDATE</command>s and
|
||||
Indexes can also benefit <command>UPDATE</command>s and
|
||||
<command>DELETE</command>s with search conditions. Note that a
|
||||
query or data manipulation commands can only use at most one index
|
||||
per table. Indices can also be used in table join methods. Thus,
|
||||
per table. Indexes can also be used in table join methods. Thus,
|
||||
an index defined on a column that is part of a join condition can
|
||||
significantly speed up queries with joins.
|
||||
</para>
|
||||
@ -99,13 +94,13 @@ CREATE INDEX test1_id_index ON test1 (id);
|
||||
<para>
|
||||
When an index is created, it has to be kept synchronized with the
|
||||
table. This adds overhead to data manipulation operations.
|
||||
Therefore indices that are non-essential or do not get used at all
|
||||
Therefore indexes that are non-essential or do not get used at all
|
||||
should be removed.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1 id="indices-types">
|
||||
<sect1 id="indexes-types">
|
||||
<title>Index Types</title>
|
||||
|
||||
<para>
|
||||
@ -113,12 +108,12 @@ CREATE INDEX test1_id_index ON test1 (id);
|
||||
B-tree, R-tree, and Hash. Each index type is more appropriate for
|
||||
a particular query type because of the algorithm it uses.
|
||||
<indexterm>
|
||||
<primary>indices</primary>
|
||||
<primary>indexes</primary>
|
||||
<secondary>B-tree</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>B-tree</primary>
|
||||
<see>indices</see>
|
||||
<see>indexes</see>
|
||||
</indexterm>
|
||||
By
|
||||
default, the <command>CREATE INDEX</command> command will create a
|
||||
@ -138,14 +133,14 @@ CREATE INDEX test1_id_index ON test1 (id);
|
||||
|
||||
<para>
|
||||
<indexterm>
|
||||
<primary>indices</primary>
|
||||
<primary>indexes</primary>
|
||||
<secondary>R-tree</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>R-tree</primary>
|
||||
<see>indices</see>
|
||||
<see>indexes</see>
|
||||
</indexterm>
|
||||
R-tree indices are especially suited for spacial data. To create
|
||||
R-tree indexes are especially suited for spacial data. To create
|
||||
an R-tree index, use a command of the form
|
||||
<synopsis>
|
||||
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING RTREE (<replaceable>column</replaceable>);
|
||||
@ -169,12 +164,12 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
|
||||
|
||||
<para>
|
||||
<indexterm>
|
||||
<primary>indices</primary>
|
||||
<primary>indexes</primary>
|
||||
<secondary>hash</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>hash</primary>
|
||||
<see>indices</see>
|
||||
<see>indexes</see>
|
||||
</indexterm>
|
||||
The query optimizer will consider using a hash index whenever an
|
||||
indexed column is involved in a comparison using the
|
||||
@ -185,12 +180,12 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
|
||||
</synopsis>
|
||||
<note>
|
||||
<para>
|
||||
Because of the limited utility of hash indices, a B-tree index
|
||||
Because of the limited utility of hash indexes, a B-tree index
|
||||
should generally be preferred over a hash index. We do not have
|
||||
sufficient evidence that hash indices are actually faster than
|
||||
sufficient evidence that hash indexes are actually faster than
|
||||
B-trees even for <literal>=</literal> comparisons. Moreover,
|
||||
hash indices require coarser locks; see <xref
|
||||
linkend="locking-indices">.
|
||||
hash indexes require coarser locks; see <xref
|
||||
linkend="locking-indexes">.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
@ -208,11 +203,11 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1 id="indices-multicolumn">
|
||||
<title>Multi-Column Indices</title>
|
||||
<sect1 id="indexes-multicolumn">
|
||||
<title>Multi-Column Indexes</title>
|
||||
|
||||
<indexterm zone="indices-multicolumn">
|
||||
<primary>indices</primary>
|
||||
<indexterm zone="indexes-multicolumn">
|
||||
<primary>indexes</primary>
|
||||
<secondary>multi-column</secondary>
|
||||
</indexterm>
|
||||
|
||||
@ -241,7 +236,7 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
|
||||
|
||||
<para>
|
||||
Currently, only the B-tree implementation supports multi-column
|
||||
indices. Up to 16 columns may be specified. (This limit can be
|
||||
indexes. Up to 16 columns may be specified. (This limit can be
|
||||
altered when building <productname>Postgres</productname>; see the
|
||||
file <filename>config.h</filename>.)
|
||||
</para>
|
||||
@ -274,7 +269,7 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Multi-column indices should be used sparingly. Most of the time,
|
||||
Multi-column indexes should be used sparingly. Most of the time,
|
||||
an index on a single column is sufficient and saves space and time.
|
||||
Indexes with more than three columns are almost certainly
|
||||
inappropriate.
|
||||
@ -282,11 +277,11 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1 id="indices-unique">
|
||||
<title>Unique Indices</title>
|
||||
<sect1 id="indexes-unique">
|
||||
<title>Unique Indexes</title>
|
||||
|
||||
<indexterm zone="indices-unique">
|
||||
<primary>indices</primary>
|
||||
<indexterm zone="indexes-unique">
|
||||
<primary>indexes</primary>
|
||||
<secondary>unique</secondary>
|
||||
</indexterm>
|
||||
|
||||
@ -296,7 +291,7 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
|
||||
<synopsis>
|
||||
CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> (<replaceable>column</replaceable> <optional>, ...</optional>);
|
||||
</synopsis>
|
||||
Only B-tree indices can be declared unique.
|
||||
Only B-tree indexes can be declared unique.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -307,7 +302,7 @@ CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</repla
|
||||
|
||||
<para>
|
||||
<productname>PostgreSQL</productname> automatically creates unique
|
||||
indices when a table is declared with a unique constraint or a
|
||||
indexes when a table is declared with a unique constraint or a
|
||||
primary key, on the columns that make up the primary key or unique
|
||||
columns (a multi-column index, if appropriate), to enforce that
|
||||
constraint. A unique index can be added to a table at any later
|
||||
@ -317,18 +312,18 @@ CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</repla
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1 id="indices-functional">
|
||||
<title>Functional Indices</title>
|
||||
<sect1 id="indexes-functional">
|
||||
<title>Functional Indexes</title>
|
||||
|
||||
<indexterm zone="indices-functional">
|
||||
<primary>indices</primary>
|
||||
<indexterm zone="indexes-functional">
|
||||
<primary>indexes</primary>
|
||||
<secondary>on functions</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
For a <firstterm>functional index</firstterm>, an index is defined
|
||||
on the result of a function applied to one or more columns of a
|
||||
single table. Functional indices can be used to obtain fast access
|
||||
single table. Functional indexes can be used to obtain fast access
|
||||
to data based on the result of function calls.
|
||||
</para>
|
||||
|
||||
@ -349,9 +344,9 @@ CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
|
||||
<para>
|
||||
The function in the index definition can take more than one
|
||||
argument, but they must be table columns, not constants.
|
||||
Functional indices are always single-column (namely, the function
|
||||
Functional indexes are always single-column (namely, the function
|
||||
result) even if the function uses more than one input field; there
|
||||
cannot be multi-column indices that contain function calls.
|
||||
cannot be multi-column indexes that contain function calls.
|
||||
</para>
|
||||
|
||||
<tip>
|
||||
@ -364,7 +359,7 @@ CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1 id="indices-opclass">
|
||||
<sect1 id="indexes-opclass">
|
||||
<title>Operator Classes</title>
|
||||
|
||||
<para>
|
||||
@ -390,7 +385,7 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
|
||||
<listitem>
|
||||
<para>
|
||||
The operator classes <literal>box_ops</literal> and
|
||||
<literal>bigbox_ops</literal> both support R-tree indices on the
|
||||
<literal>bigbox_ops</literal> both support R-tree indexes on the
|
||||
<literal>box</literal> data type. The difference between them is
|
||||
that <literal>bigbox_ops</literal> scales box coordinates down,
|
||||
to avoid floating point exceptions from doing multiplication,
|
||||
@ -540,11 +535,11 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
|
||||
<para>
|
||||
As for why no non-unique keys are defined explicitly in standard
|
||||
<acronym>SQL</acronym> syntax? Well, you
|
||||
must understand that indices are implementation-dependent.
|
||||
must understand that indexes are implementation-dependent.
|
||||
<acronym>SQL</acronym> does not
|
||||
define the implementation, merely the relations between data in the
|
||||
database. <productname>Postgres</productname> does allow
|
||||
non-unique indices, but indices
|
||||
non-unique indexes, but indexes
|
||||
used to enforce <acronym>SQL</acronym> keys are always unique.
|
||||
</para>
|
||||
|
||||
@ -579,7 +574,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
|
||||
<acronym>RDBMS</acronym> provider gives you
|
||||
- be it an index, my imaginary MEMSTORE command, or an intelligent
|
||||
<acronym>RDBMS</acronym>
|
||||
that creates indices without your knowledge based on the fact that you have
|
||||
that creates indexes without your knowledge based on the fact that you have
|
||||
sent it many queries based on a specific combination of keys... (It learns
|
||||
from experience).
|
||||
</para>
|
||||
@ -587,10 +582,10 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
|
||||
|
||||
|
||||
<sect1 id="partial-index">
|
||||
<title id="partial-index-title">Partial Indices</title>
|
||||
<title id="partial-index-title">Partial Indexes</title>
|
||||
|
||||
<indexterm zone="partial-index">
|
||||
<primary>indices</primary>
|
||||
<primary>indexes</primary>
|
||||
<secondary>partial</secondary>
|
||||
</indexterm>
|
||||
|
||||
@ -611,7 +606,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
|
||||
<note>
|
||||
<title>Note</title>
|
||||
<para>
|
||||
Partial indices are not currently supported by
|
||||
Partial indexes are not currently supported by
|
||||
<productname>PostgreSQL</productname>, but they were once supported
|
||||
by its predecessor <productname>Postgres</productname>, and much
|
||||
of the code is still there. We hope to revive support for this
|
||||
@ -623,14 +618,14 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
|
||||
A <firstterm>partial index</firstterm>
|
||||
is an index built over a subset of a table; the subset is defined by
|
||||
a predicate. <productname>Postgres</productname>
|
||||
supported partial indices with arbitrary
|
||||
supported partial indexes with arbitrary
|
||||
predicates. I believe IBM's <productname>DB2</productname>
|
||||
for AS/400 supports partial indices
|
||||
for AS/400 supports partial indexes
|
||||
using single-clause predicates.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The main motivation for partial indices is this:
|
||||
The main motivation for partial indexes is this:
|
||||
if all of the queries you ask that can
|
||||
profitably use an index fall into a certain range, why build an index
|
||||
over the whole table and suffer the associated space/time costs?
|
||||
@ -640,9 +635,9 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The machinery to build, update and query partial indices isn't too
|
||||
bad. The hairy parts are index selection (which indices do I build?)
|
||||
and query optimization (which indices do I use?); i.e., the parts
|
||||
The machinery to build, update and query partial indexes isn't too
|
||||
bad. The hairy parts are index selection (which indexes do I build?)
|
||||
and query optimization (which indexes do I use?); i.e., the parts
|
||||
that involve deciding what predicate(s) match the workload/query in
|
||||
some useful way. For those who are into database theory, the problems
|
||||
are basically analogous to the corresponding materialized view
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.14 2001/05/12 22:51:35 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.15 2001/05/17 21:50:16 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="mvcc">
|
||||
@ -554,8 +554,8 @@ ERROR: Can't serialize access due to concurrent update
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="locking-indices">
|
||||
<title>Locking and Indices</title>
|
||||
<sect1 id="locking-indexes">
|
||||
<title>Locking and Indexes</title>
|
||||
|
||||
<para>
|
||||
Though <productname>Postgres</productname>
|
||||
@ -571,7 +571,7 @@ ERROR: Can't serialize access due to concurrent update
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
GiST and R-Tree indices
|
||||
GiST and R-Tree indexes
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -583,7 +583,7 @@ ERROR: Can't serialize access due to concurrent update
|
||||
|
||||
<varlistentry>
|
||||
<term>
|
||||
Hash indices
|
||||
Hash indexes
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -600,7 +600,7 @@ ERROR: Can't serialize access due to concurrent update
|
||||
|
||||
<varlistentry>
|
||||
<term>
|
||||
Btree indices
|
||||
B-tree indexes
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
@ -610,7 +610,7 @@ ERROR: Can't serialize access due to concurrent update
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Btree indices provide the highest concurrency without deadlock
|
||||
B-tree indexes provide the highest concurrency without deadlock
|
||||
conditions.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -619,7 +619,7 @@ ERROR: Can't serialize access due to concurrent update
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In short, btree indices are the recommended index type for concurrent
|
||||
In short, B-tree indexes are the recommended index type for concurrent
|
||||
applications.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
@ -23,7 +23,7 @@ refers to data that is stored in <productname>Postgres</productname> tables.
|
||||
|
||||
<para>
|
||||
The following table shows how pages in both normal <productname>Postgres</productname> tables
|
||||
and <productname>Postgres</productname> indices
|
||||
and <productname>Postgres</productname> indexes
|
||||
(e.g., a B-tree index) are structured.
|
||||
|
||||
<table tocentry="1">
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.4 2001/05/09 00:35:09 tgl Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.5 2001/05/17 21:50:16 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="performance-tips">
|
||||
@ -395,8 +395,8 @@ SELECT * FROM d LEFT JOIN
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="populate-rm-indices">
|
||||
<title>Remove Indices</title>
|
||||
<sect2 id="populate-rm-indexes">
|
||||
<title>Remove Indexes</title>
|
||||
|
||||
<para>
|
||||
If you are loading a freshly created table, the fastest way is to
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.31 2001/05/12 22:51:35 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.32 2001/05/17 21:50:16 petere Exp $
|
||||
-->
|
||||
|
||||
<chapter id="plpgsql">
|
||||
@ -115,7 +115,7 @@ END;
|
||||
for user defined types, anything that can be defined in C language
|
||||
functions can also be done with PL/pgSQL. It is possible to
|
||||
create complex conditional computation functions and later use
|
||||
them to define operators or use them in functional indices.
|
||||
them to define operators or use them in functional indexes.
|
||||
</para>
|
||||
<sect2 id="plpgsql-advantages">
|
||||
<title>Advantages of Using PL/pgSQL</title>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.18 2001/01/13 23:58:55 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.19 2001/05/17 21:50:18 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -209,7 +209,7 @@ ERROR: Cannot create index: 'index_name' already exists.
|
||||
on the result of a user-specified function
|
||||
<replaceable class="parameter">func_name</replaceable> applied
|
||||
to one or more columns of a single table.
|
||||
These <firstterm>functional indices</firstterm>
|
||||
These <firstterm>functional indexes</firstterm>
|
||||
can be used to obtain fast access to data
|
||||
based on operators that would normally require some
|
||||
transformation to apply them to the base data.
|
||||
@ -217,7 +217,7 @@ ERROR: Cannot create index: 'index_name' already exists.
|
||||
|
||||
<para>
|
||||
Postgres provides btree, rtree and hash access methods for
|
||||
indices. The btree access method is an implementation of
|
||||
indexes. The btree access method is an implementation of
|
||||
Lehman-Yao high-concurrency btrees. The rtree access method
|
||||
implements standard rtrees using Guttman's quadratic split algorithm.
|
||||
The hash access method is an implementation of Litwin's linear
|
||||
@ -302,7 +302,7 @@ ERROR: Cannot create index: 'index_name' already exists.
|
||||
<listitem>
|
||||
<para>
|
||||
The operator classes <literal>box_ops</literal> and
|
||||
<literal>bigbox_ops</literal> both support rtree indices on the
|
||||
<literal>bigbox_ops</literal> both support rtree indexes on the
|
||||
<literal>box</literal> data type.
|
||||
The difference between them is that <literal>bigbox_ops</literal>
|
||||
scales box coordinates down, to avoid floating-point exceptions from
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v 1.32 2001/05/17 21:12:48 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v 1.33 2001/05/17 21:50:18 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -74,7 +74,7 @@ Postgres documentation
|
||||
<para>
|
||||
<command>pg_dump</command>
|
||||
will produce the queries necessary to re-generate all
|
||||
user-defined types, functions, tables, indices, aggregates, and
|
||||
user-defined types, functions, tables, indexes, aggregates, and
|
||||
operators. In addition, all the data is copied out in text format so
|
||||
that it can be readily copied in again, as well as imported into tools
|
||||
for editing.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.11 2001/05/17 21:12:48 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.12 2001/05/17 21:50:18 petere Exp $ -->
|
||||
|
||||
<refentry id="APP-PGRESTORE">
|
||||
<docinfo>
|
||||
@ -71,7 +71,7 @@
|
||||
or even to reorder the items prior to being restored. The archive files are designed
|
||||
to be portable across architectures. <command>pg_dump</command> will
|
||||
produce the queries necessary to re-generate all user-defined types, functions,
|
||||
tables, indices, aggregates, and operators. In addition, all the data is copied
|
||||
tables, indexes, aggregates, and operators. In addition, all the data is copied
|
||||
out (in text format for scripts) so that it can be readily copied in again.
|
||||
</para>
|
||||
|
||||
@ -335,7 +335,7 @@
|
||||
<para>
|
||||
Restore items in modified OID order. By default <command>pg_dump</command> will dump items in an order convenient
|
||||
to <command>pg_dump</command>, then save the archive in a modified OID order. Most objects
|
||||
will be restored in OID order, but some things (e.g., rules and indices) will be restored at the end of
|
||||
will be restored in OID order, but some things (e.g., rules and indexes) will be restored at the end of
|
||||
the process irrespective of their OIDs. This option is the default.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/Attic/pgaccess-ref.sgml,v 1.9 2001/03/17 16:27:31 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/Attic/pgaccess-ref.sgml,v 1.10 2001/05/17 21:50:18 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -163,7 +163,7 @@ Postgres documentation
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Retrieve information on tables, including owner, field information, indices.
|
||||
Retrieve information on tables, including owner, field information, indexes.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.52 2001/05/12 19:44:45 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.53 2001/05/17 21:50:18 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
@ -348,7 +348,7 @@ testdb=>
|
||||
(which could be a table, view, index, or sequence),
|
||||
their types, and any special attributes such as <literal>NOT NULL</literal>
|
||||
or defaults, if any.
|
||||
If the relation is, in fact, a table, any defined indices are also listed.
|
||||
If the relation is, in fact, a table, any defined indexes are also listed.
|
||||
If the relation is a view, the view definition is also shown.
|
||||
</para>
|
||||
|
||||
@ -387,7 +387,7 @@ testdb=>
|
||||
Shows the descriptions of <replaceable class="parameter">object</replaceable>
|
||||
(which can be a regular expression), or of all objects if no argument is given.
|
||||
(<quote>Object</quote> covers aggregates, functions, operators, types, relations
|
||||
(tables, views, indices, sequences, large objects), rules, and triggers.) For example:
|
||||
(tables, views, indexes, sequences, large objects), rules, and triggers.) For example:
|
||||
<programlisting>
|
||||
=> <userinput>\dd version</userinput>
|
||||
Object descriptions
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.92 2001/05/17 13:28:30 momjian Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.93 2001/05/17 21:50:16 petere Exp $
|
||||
-->
|
||||
|
||||
<appendix id="release">
|
||||
@ -1196,7 +1196,7 @@ subselect+CASE fixes(Tom)
|
||||
Add SHLIB_LINK setting for solaris_i386 and solaris_sparc ports(Daren Sefcik)
|
||||
Fixes for CASE in WHERE join clauses(Tom)
|
||||
Fix BTScan abort(Tom)
|
||||
Repair the check for redundant UNIQUE and PRIMARY KEY indices(Thomas)
|
||||
Repair the check for redundant UNIQUE and PRIMARY KEY indexes(Thomas)
|
||||
Improve it so that it checks for multi-column constraints(Thomas)
|
||||
Fix for Win32 making problem with MB enabled(Hiroki Kataoka)
|
||||
Allow BSD yacc and bison to compile pl code(Bruce)
|
||||
@ -1595,7 +1595,7 @@ Enhancements
|
||||
------------
|
||||
Add "vacuumdb" utility
|
||||
Speed up libpq by allocating memory better(Tom)
|
||||
EXPLAIN all indices used(Tom)
|
||||
EXPLAIN all indexes used(Tom)
|
||||
Implement CASE, COALESCE, NULLIF expression(Thomas)
|
||||
New pg_dump table output format(Constantin)
|
||||
Add string min()/max() functions(Thomas)
|
||||
@ -2029,14 +2029,14 @@ Allow index use with OR clauses(Bruce)
|
||||
Allows "SELECT NULL ORDER BY 1;"
|
||||
Explain VERBOSE prints the plan, and now pretty-prints the plan to
|
||||
the postmaster log file(Bruce)
|
||||
Add Indices display to \d command(Bruce)
|
||||
Add indexes display to \d command(Bruce)
|
||||
Allow GROUP BY on functions(David)
|
||||
New pg_class.relkind for large objects(Bruce)
|
||||
New way to send libpq NOTICE messages to a different location(Tom)
|
||||
New \w write command to psql(Bruce)
|
||||
New /contrib/findoidjoins scans oid columns to find join relationships(Bruce)
|
||||
Allow binary-compatible indices to be considered when checking for valid
|
||||
indices for restriction clauses containing a constant(Thomas)
|
||||
Allow binary-compatible indexes to be considered when checking for valid
|
||||
Indexes for restriction clauses containing a constant(Thomas)
|
||||
New ISBN/ISSN code in /contrib/isbn_issn
|
||||
Allow NOT LIKE, IN, NOT IN, BETWEEN, and NOT BETWEEN constraint(Thomas)
|
||||
New rewrite system fixes many problems with rules and views(Jan)
|
||||
@ -2502,7 +2502,7 @@ Real deadlock detection, no more timeouts(Bruce)
|
||||
Add SQL92 "constants" CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP,
|
||||
CURRENT_USER(Thomas)
|
||||
Modify constraint syntax to be SQL92-compliant(Thomas)
|
||||
Implement SQL92 PRIMARY KEY and UNIQUE clauses using indices(Thomas)
|
||||
Implement SQL92 PRIMARY KEY and UNIQUE clauses using indexes(Thomas)
|
||||
Recognize SQL92 syntax for FOREIGN KEY. Throw elog notice(Thomas)
|
||||
Allow NOT NULL UNIQUE constraint clause (each allowed separately before)(Thomas)
|
||||
Allow Postgres-style casting ("::") of non-constants(Thomas)
|
||||
@ -2514,14 +2514,14 @@ Implement SQL92 binary and hexadecimal string decoding (b'10' and x'1F')(Thomas)
|
||||
Support SQL92 syntax for type coercion of literal strings
|
||||
(e.g. "DATETIME 'now'")(Thomas)
|
||||
Add conversions for int2, int4, and OID types to and from text(Thomas)
|
||||
Use shared lock when building indices(Vadim)
|
||||
Use shared lock when building indexes(Vadim)
|
||||
Free memory allocated for an user query inside transaction block after
|
||||
this query is done, was turned off in <= 6.2.1(Vadim)
|
||||
New SQL statement CREATE PROCEDURAL LANGUAGE(Jan)
|
||||
New <productname>Postgres</productname> Procedural Language (PL) backend interface(Jan)
|
||||
Rename pg_dump -H option to -h(Bruce)
|
||||
Add Java support for passwords, European dates(Peter)
|
||||
Use indices for LIKE and ~, !~ operations(Bruce)
|
||||
Use indexes for LIKE and ~, !~ operations(Bruce)
|
||||
Add hash functions for datetime and timespan(Thomas)
|
||||
Time Travel removed(Vadim, Bruce)
|
||||
Add paging for \d and \z, and fix \i(Bruce)
|
||||
@ -2539,7 +2539,7 @@ Regression tests time zone automatically set with "setenv PGTZ PST8PDT"(Thomas)
|
||||
Add pg_description table for info on tables, columns, operators, types, and
|
||||
aggregates(Bruce)
|
||||
Increase 16 char limit on system table/index names to 32 characters(Bruce)
|
||||
Rename system indices(Bruce)
|
||||
Rename system indexes(Bruce)
|
||||
Add 'GERMAN' option to SET DATESTYLE(Thomas)
|
||||
Define an "ISO-style" timespan output format with "hh:mm:ss" fields(Thomas)
|
||||
Allow fractional values for delta times (e.g. '2.5 days')(Thomas)
|
||||
@ -3041,7 +3041,7 @@ fix join clauses for multiple tables(Vadim)
|
||||
fix hash, hashjoin for arrays(Vadim)
|
||||
fix btree for abstime type(Vadim)
|
||||
large object fixes(Raymond)
|
||||
fix buffer leak in hash indices (Vadim)
|
||||
fix buffer leak in hash indexes (Vadim)
|
||||
fix rtree for use in inner scan (Vadim)
|
||||
fix gist for use in inner scan, cleanups (Vadim, Andrea)
|
||||
avoid unnecessary local buffers allocation (Vadim, Massimo)
|
||||
@ -3816,8 +3816,8 @@ Bug fixes:
|
||||
* allow the use of \; inside the monitor
|
||||
* the LISTEN/NOTIFY asynchronous notification mechanism now work
|
||||
* NOTIFY in rule action bodies now work
|
||||
* hash indices work, and access methods in general should perform better.
|
||||
creation of large btree indices should be much faster. (thanks to Paul
|
||||
* hash indexes work, and access methods in general should perform better.
|
||||
creation of large btree indexes should be much faster. (thanks to Paul
|
||||
Aoki)
|
||||
|
||||
Other changes and enhancements:
|
||||
|
||||
@ -1869,7 +1869,7 @@ Merge Join
|
||||
AND software.hostname = computer.hostname;
|
||||
</ProgramListing>
|
||||
|
||||
Since there are appropriate indices setup, the planner
|
||||
Since there are appropriate indexes setup, the planner
|
||||
will create a plan of
|
||||
|
||||
<ProgramListing>
|
||||
@ -1919,7 +1919,7 @@ Merge Join
|
||||
get invoked once for any of the 2000 old computers that
|
||||
have to be deleted and that will result in one index scan
|
||||
over computer and 2000 index scans for the software. The
|
||||
rule implementation will do it with two queries over indices.
|
||||
rule implementation will do it with two queries over indexes.
|
||||
And it depends on the overall size of the software table if
|
||||
the rule will still be faster in the seqscan situation. 2000
|
||||
query executions over the SPI manager take some time, even
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.6 2001/05/15 13:57:37 momjian Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.7 2001/05/17 21:50:16 petere Exp $ -->
|
||||
|
||||
<chapter id="wal">
|
||||
<title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
|
||||
@ -18,7 +18,7 @@
|
||||
is a standard approach to transaction logging. Its detailed
|
||||
description may be found in most (if not all) books about
|
||||
transaction processing. Briefly, <acronym>WAL</acronym>'s central
|
||||
concept is that changes to data files (where tables and indices
|
||||
concept is that changes to data files (where tables and indexes
|
||||
reside) must be written only after those changes have been logged -
|
||||
that is, when log records have been flushed to permanent
|
||||
storage. When we follow this procedure, we do not need to flush
|
||||
@ -67,7 +67,7 @@
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
Problems with indices (problems 1 and 2) could possibly have been
|
||||
Problems with indexes (problems 1 and 2) could possibly have been
|
||||
fixed by additional <function>fsync()</function> calls, but it is
|
||||
not obvious how to handle the last case without
|
||||
<acronym>WAL</acronym>; <acronym>WAL</acronym> saves the entire
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.14 2001/03/24 23:03:26 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.15 2001/05/17 21:50:17 petere Exp $
|
||||
Postgres documentation
|
||||
-->
|
||||
|
||||
<chapter id="xindex">
|
||||
<title>Interfacing Extensions To Indices</title>
|
||||
<title>Interfacing Extensions To Indexes</title>
|
||||
|
||||
<para>
|
||||
The procedures described thus far let you define a new type, new
|
||||
@ -34,7 +34,7 @@ Postgres documentation
|
||||
|
||||
<table tocentry="1">
|
||||
<title>Index Schema</title>
|
||||
<titleabbrev>Indices</titleabbrev>
|
||||
|
||||
<tgroup cols="2">
|
||||
<thead>
|
||||
<row>
|
||||
@ -118,7 +118,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
|
||||
example, that the "<=" and ">" operators partition a
|
||||
<acronym>B-tree</acronym>. <productname>Postgres</productname>
|
||||
uses strategies to express these relationships between
|
||||
operators and the way they can be used to scan indices.
|
||||
operators and the way they can be used to scan indexes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
As previously mentioned, there are two kinds of types
|
||||
in <productname>Postgres</productname>: base types (defined in a programming language)
|
||||
and composite types.
|
||||
Examples in this section up to interfacing indices can
|
||||
Examples in this section up to interfacing indexes can
|
||||
be found in <filename>complex.sql</filename> and <filename>complex.c</filename>. Composite examples
|
||||
are in <filename>funcs.sql</filename>.
|
||||
</para>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user