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

Change "indices" to "indexes", per OED.

Browse Source
This commit is contained in:
Peter Eisentraut
2001-05-17 21:50:18 +00:00
parent f000ffd28e
commit a6677f0f9e
20 changed files with 121 additions and 126 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
doc/src/sgml/arch-dev.sgml
View File

@ -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"> <chapter id="overview">
@ -603,7 +603,7 @@ current context are performed.
<para> <para>
The planner/optimizer decides which plans should be generated 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 a query. There is always the possibility of performing a
sequential scan on a relation, so a plan using only sequential scan on a relation, so a plan using only
sequential scans is always created. Assume an index is defined on a 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 OPR constant</literal>. If
<literal>relation.attribute</literal> happens to match the key of the B-tree <literal>relation.attribute</literal> happens to match the key of the B-tree
index and <literal>OPR</literal> is anything but '&lt;&gt;' another plan is created using index and <literal>OPR</literal> is anything but '&lt;&gt;' 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 present and the restrictions in the query happen to match a key of an
index further plans will be considered. index further plans will be considered.
</para> </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 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} 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 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 qualifications present are attached to the {\tt Scan} node. Figure
\ref{plan_having} shows the {\it plan} created for the query given in \ref{plan_having} shows the {\it plan} created for the query given in
example \ref{having}. example \ref{having}.

4
doc/src/sgml/backup.sgml
View File

@ -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"> <chapter id="backup">
<title>Backup and Restore</title> <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 Also note that the file system backup will not necessarily be
smaller than an SQL dump. On the contrary, it will most likely be smaller than an SQL dump. On the contrary, it will most likely be
larger. (<application>pg_dump</application> does not need to dump 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.) them.)
</para> </para>

8
doc/src/sgml/extend.sgml
View File

@ -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"> <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 file that stores all rows of a table) but the
user can "look inside" at the attributes of these types user can "look inside" at the attributes of these types
from the query language and optimize their retrieval by 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 <productname>Postgres</productname> base types are further
divided into built-in divided into built-in
types and user-defined types. Built-in types (like 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>
<row> <row>
<entry>pg_index</entry> <entry>pg_index</entry>
<entry> secondary indices</entry> <entry> secondary indexes</entry>
</row> </row>
<row> <row>
<entry>pg_proc</entry> <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_am, pg_amop, pg_amproc, pg_operator and
pg_opclass are particularly hard to understand pg_opclass are particularly hard to understand
and will be described in depth (in the section 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. after we have discussed basic extensions.
</para> </para>
</listitem> </listitem>

6
doc/src/sgml/geqo.sgml
View File

@ -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 Genetic Optimizer
--> -->
@ -51,8 +51,8 @@ Genetic Optimizer
<firstterm>join methods</firstterm> <firstterm>join methods</firstterm>
(e.g., nested loop, hash join, merge join in <productname>Postgres</productname>) to (e.g., nested loop, hash join, merge join in <productname>Postgres</productname>) to
process individual <command>join</command>s and a diversity of process individual <command>join</command>s and a diversity of
<firstterm>indices</firstterm> (e.g., r-tree, <firstterm>indexes</firstterm> (e.g., R-tree,
b-tree, hash in <productname>Postgres</productname>) as access paths for relations. B-tree, hash in <productname>Postgres</productname>) as access paths for relations.
</para> </para>
<para> <para>

2
doc/src/sgml/gist.sgml
View File

@ -8,7 +8,7 @@
</AuthorGroup> </AuthorGroup>
<Date>Transcribed 1998-02-19</Date> <Date>Transcribed 1998-02-19</Date>
</DocInfo> </DocInfo>
<Title>GiST Indices</Title> <Title>GiST Indexes</Title>
<Para> <Para>
The information about GIST is at The information about GIST is at

117
doc/src/sgml/indices.sgml
View File

@ -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"> <chapter id="indexes">
<title id="indices-title">Indices</title> <title id="indexes-title">Indices</title>
<indexterm zone="indices"> <indexterm zone="indexes">
<primary>indices</primary>
</indexterm>
<indexterm>
<primary>indexes</primary> <primary>indexes</primary>
<see>indices</see>
</indexterm> </indexterm>
<para> <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 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 overhead to the database system as a whole, so they should be used
sensibly. sensibly.
</para> </para>
<sect1 id="indices-intro"> <sect1 id="indexes-intro">
<title>Introduction</title> <title>Introduction</title>
<para> <para>
@ -73,7 +68,7 @@ CREATE INDEX test1_id_index ON test1 (id);
<para> <para>
To remove an index, use the <command>DROP INDEX</command> command. 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>
<para> <para>
@ -88,10 +83,10 @@ CREATE INDEX test1_id_index ON test1 (id);
</para> </para>
<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 <command>DELETE</command>s with search conditions. Note that a
query or data manipulation commands can only use at most one index 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 an index defined on a column that is part of a join condition can
significantly speed up queries with joins. significantly speed up queries with joins.
</para> </para>
@ -99,13 +94,13 @@ CREATE INDEX test1_id_index ON test1 (id);
<para> <para>
When an index is created, it has to be kept synchronized with the When an index is created, it has to be kept synchronized with the
table. This adds overhead to data manipulation operations. 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. should be removed.
</para> </para>
</sect1> </sect1>
<sect1 id="indices-types"> <sect1 id="indexes-types">
<title>Index Types</title> <title>Index Types</title>
<para> <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 B-tree, R-tree, and Hash. Each index type is more appropriate for
a particular query type because of the algorithm it uses. a particular query type because of the algorithm it uses.
<indexterm> <indexterm>
<primary>indices</primary> <primary>indexes</primary>
<secondary>B-tree</secondary> <secondary>B-tree</secondary>
</indexterm> </indexterm>
<indexterm> <indexterm>
<primary>B-tree</primary> <primary>B-tree</primary>
<see>indices</see> <see>indexes</see>
</indexterm> </indexterm>
By By
default, the <command>CREATE INDEX</command> command will create a default, the <command>CREATE INDEX</command> command will create a
@ -138,14 +133,14 @@ CREATE INDEX test1_id_index ON test1 (id);
<para> <para>
<indexterm> <indexterm>
<primary>indices</primary> <primary>indexes</primary>
<secondary>R-tree</secondary> <secondary>R-tree</secondary>
</indexterm> </indexterm>
<indexterm> <indexterm>
<primary>R-tree</primary> <primary>R-tree</primary>
<see>indices</see> <see>indexes</see>
</indexterm> </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 an R-tree index, use a command of the form
<synopsis> <synopsis>
CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING RTREE (<replaceable>column</replaceable>); 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> <para>
<indexterm> <indexterm>
<primary>indices</primary> <primary>indexes</primary>
<secondary>hash</secondary> <secondary>hash</secondary>
</indexterm> </indexterm>
<indexterm> <indexterm>
<primary>hash</primary> <primary>hash</primary>
<see>indices</see> <see>indexes</see>
</indexterm> </indexterm>
The query optimizer will consider using a hash index whenever an The query optimizer will consider using a hash index whenever an
indexed column is involved in a comparison using the indexed column is involved in a comparison using the
@ -185,12 +180,12 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
</synopsis> </synopsis>
<note> <note>
<para> <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 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, B-trees even for <literal>=</literal> comparisons. Moreover,
hash indices require coarser locks; see <xref hash indexes require coarser locks; see <xref
linkend="locking-indices">. linkend="locking-indexes">.
</para> </para>
</note> </note>
</para> </para>
@ -208,11 +203,11 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
</sect1> </sect1>
<sect1 id="indices-multicolumn"> <sect1 id="indexes-multicolumn">
<title>Multi-Column Indices</title> <title>Multi-Column Indexes</title>
<indexterm zone="indices-multicolumn"> <indexterm zone="indexes-multicolumn">
<primary>indices</primary> <primary>indexes</primary>
<secondary>multi-column</secondary> <secondary>multi-column</secondary>
</indexterm> </indexterm>
@ -241,7 +236,7 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
<para> <para>
Currently, only the B-tree implementation supports multi-column 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 altered when building <productname>Postgres</productname>; see the
file <filename>config.h</filename>.) file <filename>config.h</filename>.)
</para> </para>
@ -274,7 +269,7 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
</para> </para>
<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. an index on a single column is sufficient and saves space and time.
Indexes with more than three columns are almost certainly Indexes with more than three columns are almost certainly
inappropriate. inappropriate.
@ -282,11 +277,11 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
</sect1> </sect1>
<sect1 id="indices-unique"> <sect1 id="indexes-unique">
<title>Unique Indices</title> <title>Unique Indexes</title>
<indexterm zone="indices-unique"> <indexterm zone="indexes-unique">
<primary>indices</primary> <primary>indexes</primary>
<secondary>unique</secondary> <secondary>unique</secondary>
</indexterm> </indexterm>
@ -296,7 +291,7 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
<synopsis> <synopsis>
CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> (<replaceable>column</replaceable> <optional>, ...</optional>); CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> (<replaceable>column</replaceable> <optional>, ...</optional>);
</synopsis> </synopsis>
Only B-tree indices can be declared unique. Only B-tree indexes can be declared unique.
</para> </para>
<para> <para>
@ -307,7 +302,7 @@ CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</repla
<para> <para>
<productname>PostgreSQL</productname> automatically creates unique <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 primary key, on the columns that make up the primary key or unique
columns (a multi-column index, if appropriate), to enforce that columns (a multi-column index, if appropriate), to enforce that
constraint. A unique index can be added to a table at any later 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>
<sect1 id="indices-functional"> <sect1 id="indexes-functional">
<title>Functional Indices</title> <title>Functional Indexes</title>
<indexterm zone="indices-functional"> <indexterm zone="indexes-functional">
<primary>indices</primary> <primary>indexes</primary>
<secondary>on functions</secondary> <secondary>on functions</secondary>
</indexterm> </indexterm>
<para> <para>
For a <firstterm>functional index</firstterm>, an index is defined For a <firstterm>functional index</firstterm>, an index is defined
on the result of a function applied to one or more columns of a 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. to data based on the result of function calls.
</para> </para>
@ -349,9 +344,9 @@ CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
<para> <para>
The function in the index definition can take more than one The function in the index definition can take more than one
argument, but they must be table columns, not constants. 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 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> </para>
<tip> <tip>
@ -364,7 +359,7 @@ CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
</sect1> </sect1>
<sect1 id="indices-opclass"> <sect1 id="indexes-opclass">
<title>Operator Classes</title> <title>Operator Classes</title>
<para> <para>
@ -390,7 +385,7 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
<listitem> <listitem>
<para> <para>
The operator classes <literal>box_ops</literal> and 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 <literal>box</literal> data type. The difference between them is
that <literal>bigbox_ops</literal> scales box coordinates down, that <literal>bigbox_ops</literal> scales box coordinates down,
to avoid floating point exceptions from doing multiplication, to avoid floating point exceptions from doing multiplication,
@ -540,11 +535,11 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
<para> <para>
As for why no non-unique keys are defined explicitly in standard As for why no non-unique keys are defined explicitly in standard
<acronym>SQL</acronym> syntax? Well, you <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 <acronym>SQL</acronym> does not
define the implementation, merely the relations between data in the define the implementation, merely the relations between data in the
database. <productname>Postgres</productname> does allow 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. used to enforce <acronym>SQL</acronym> keys are always unique.
</para> </para>
@ -579,7 +574,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
<acronym>RDBMS</acronym> provider gives you <acronym>RDBMS</acronym> provider gives you
- be it an index, my imaginary MEMSTORE command, or an intelligent - be it an index, my imaginary MEMSTORE command, or an intelligent
<acronym>RDBMS</acronym> <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 sent it many queries based on a specific combination of keys... (It learns
from experience). from experience).
</para> </para>
@ -587,10 +582,10 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
<sect1 id="partial-index"> <sect1 id="partial-index">
<title id="partial-index-title">Partial Indices</title> <title id="partial-index-title">Partial Indexes</title>
<indexterm zone="partial-index"> <indexterm zone="partial-index">
<primary>indices</primary> <primary>indexes</primary>
<secondary>partial</secondary> <secondary>partial</secondary>
</indexterm> </indexterm>
@ -611,7 +606,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
<note> <note>
<title>Note</title> <title>Note</title>
<para> <para>
Partial indices are not currently supported by Partial indexes are not currently supported by
<productname>PostgreSQL</productname>, but they were once supported <productname>PostgreSQL</productname>, but they were once supported
by its predecessor <productname>Postgres</productname>, and much by its predecessor <productname>Postgres</productname>, and much
of the code is still there. We hope to revive support for this 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> A <firstterm>partial index</firstterm>
is an index built over a subset of a table; the subset is defined by is an index built over a subset of a table; the subset is defined by
a predicate. <productname>Postgres</productname> a predicate. <productname>Postgres</productname>
supported partial indices with arbitrary supported partial indexes with arbitrary
predicates. I believe IBM's <productname>DB2</productname> predicates. I believe IBM's <productname>DB2</productname>
for AS/400 supports partial indices for AS/400 supports partial indexes
using single-clause predicates. using single-clause predicates.
</para> </para>
<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 if all of the queries you ask that can
profitably use an index fall into a certain range, why build an index profitably use an index fall into a certain range, why build an index
over the whole table and suffer the associated space/time costs? 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>
<para> <para>
The machinery to build, update and query partial indices isn't too The machinery to build, update and query partial indexes isn't too
bad. The hairy parts are index selection (which indices do I build?) bad. The hairy parts are index selection (which indexes do I build?)
and query optimization (which indices do I use?); i.e., the parts and query optimization (which indexes do I use?); i.e., the parts
that involve deciding what predicate(s) match the workload/query in that involve deciding what predicate(s) match the workload/query in
some useful way. For those who are into database theory, the problems some useful way. For those who are into database theory, the problems
are basically analogous to the corresponding materialized view are basically analogous to the corresponding materialized view

16
doc/src/sgml/mvcc.sgml
View File

@ -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"> <chapter id="mvcc">
@ -554,8 +554,8 @@ ERROR: Can't serialize access due to concurrent update
</sect2> </sect2>
</sect1> </sect1>
<sect1 id="locking-indices"> <sect1 id="locking-indexes">
<title>Locking and Indices</title> <title>Locking and Indexes</title>
<para> <para>
Though <productname>Postgres</productname> Though <productname>Postgres</productname>
@ -571,7 +571,7 @@ ERROR: Can't serialize access due to concurrent update
<variablelist> <variablelist>
<varlistentry> <varlistentry>
<term> <term>
GiST and R-Tree indices GiST and R-Tree indexes
</term> </term>
<listitem> <listitem>
<para> <para>
@ -583,7 +583,7 @@ ERROR: Can't serialize access due to concurrent update
<varlistentry> <varlistentry>
<term> <term>
Hash indices Hash indexes
</term> </term>
<listitem> <listitem>
<para> <para>
@ -600,7 +600,7 @@ ERROR: Can't serialize access due to concurrent update
<varlistentry> <varlistentry>
<term> <term>
Btree indices B-tree indexes
</term> </term>
<listitem> <listitem>
<para> <para>
@ -610,7 +610,7 @@ ERROR: Can't serialize access due to concurrent update
</para> </para>
<para> <para>
Btree indices provide the highest concurrency without deadlock B-tree indexes provide the highest concurrency without deadlock
conditions. conditions.
</para> </para>
</listitem> </listitem>
@ -619,7 +619,7 @@ ERROR: Can't serialize access due to concurrent update
</para> </para>
<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. applications.
</para> </para>
</sect1> </sect1>

2
doc/src/sgml/page.sgml
View File

@ -23,7 +23,7 @@ refers to data that is stored in <productname>Postgres</productname> tables.
<para> <para>
The following table shows how pages in both normal <productname>Postgres</productname> tables 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. (e.g., a B-tree index) are structured.
<table tocentry="1"> <table tocentry="1">

6
doc/src/sgml/perform.sgml
View File

@ -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"> <chapter id="performance-tips">
@ -395,8 +395,8 @@ SELECT * FROM d LEFT JOIN
</para> </para>
</sect2> </sect2>
<sect2 id="populate-rm-indices"> <sect2 id="populate-rm-indexes">
<title>Remove Indices</title> <title>Remove Indexes</title>
<para> <para>
If you are loading a freshly created table, the fastest way is to If you are loading a freshly created table, the fastest way is to

4
doc/src/sgml/plsql.sgml
View File

@ -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"> <chapter id="plpgsql">
@ -115,7 +115,7 @@ END;
for user defined types, anything that can be defined in C language for user defined types, anything that can be defined in C language
functions can also be done with PL/pgSQL. It is possible to functions can also be done with PL/pgSQL. It is possible to
create complex conditional computation functions and later use 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> </para>
<sect2 id="plpgsql-advantages"> <sect2 id="plpgsql-advantages">
<title>Advantages of Using PL/pgSQL</title> <title>Advantages of Using PL/pgSQL</title>

8
doc/src/sgml/ref/create_index.sgml
View File

@ -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 Postgres documentation
--> -->
@ -209,7 +209,7 @@ ERROR: Cannot create index: 'index_name' already exists.
on the result of a user-specified function on the result of a user-specified function
<replaceable class="parameter">func_name</replaceable> applied <replaceable class="parameter">func_name</replaceable> applied
to one or more columns of a single table. 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 can be used to obtain fast access to data
based on operators that would normally require some based on operators that would normally require some
transformation to apply them to the base data. transformation to apply them to the base data.
@ -217,7 +217,7 @@ ERROR: Cannot create index: 'index_name' already exists.
<para> <para>
Postgres provides btree, rtree and hash access methods for 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 Lehman-Yao high-concurrency btrees. The rtree access method
implements standard rtrees using Guttman's quadratic split algorithm. implements standard rtrees using Guttman's quadratic split algorithm.
The hash access method is an implementation of Litwin's linear The hash access method is an implementation of Litwin's linear
@ -302,7 +302,7 @@ ERROR: Cannot create index: 'index_name' already exists.
<listitem> <listitem>
<para> <para>
The operator classes <literal>box_ops</literal> and 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. <literal>box</literal> data type.
The difference between them is that <literal>bigbox_ops</literal> The difference between them is that <literal>bigbox_ops</literal>
scales box coordinates down, to avoid floating-point exceptions from scales box coordinates down, to avoid floating-point exceptions from

4
doc/src/sgml/ref/pg_dump.sgml
View File

@ -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 Postgres documentation
--> -->
@ -74,7 +74,7 @@ Postgres documentation
<para> <para>
<command>pg_dump</command> <command>pg_dump</command>
will produce the queries necessary to re-generate all 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 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 that it can be readily copied in again, as well as imported into tools
for editing. for editing.

6
doc/src/sgml/ref/pg_restore.sgml
View File

@ -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"> <refentry id="APP-PGRESTORE">
<docinfo> <docinfo>
@ -71,7 +71,7 @@
or even to reorder the items prior to being restored. The archive files are designed 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 to be portable across architectures. <command>pg_dump</command> will
produce the queries necessary to re-generate all user-defined types, functions, 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. out (in text format for scripts) so that it can be readily copied in again.
</para> </para>
@ -335,7 +335,7 @@
<para> <para>
Restore items in modified OID order. By default <command>pg_dump</command> will dump items in an order convenient 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 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. the process irrespective of their OIDs. This option is the default.
</para> </para>
</listitem> </listitem>

4
doc/src/sgml/ref/pgaccess-ref.sgml
View File

@ -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 Postgres documentation
--> -->
@ -163,7 +163,7 @@ Postgres documentation
<listitem> <listitem>
<para> <para>
Retrieve information on tables, including owner, field information, indices. Retrieve information on tables, including owner, field information, indexes.
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>

6
doc/src/sgml/ref/psql-ref.sgml
View File

@ -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 Postgres documentation
--> -->
@ -348,7 +348,7 @@ testdb=>
(which could be a table, view, index, or sequence), (which could be a table, view, index, or sequence),
their types, and any special attributes such as <literal>NOT NULL</literal> their types, and any special attributes such as <literal>NOT NULL</literal>
or defaults, if any. 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. If the relation is a view, the view definition is also shown.
</para> </para>
@ -387,7 +387,7 @@ testdb=>
Shows the descriptions of <replaceable class="parameter">object</replaceable> Shows the descriptions of <replaceable class="parameter">object</replaceable>
(which can be a regular expression), or of all objects if no argument is given. (which can be a regular expression), or of all objects if no argument is given.
(<quote>Object</quote> covers aggregates, functions, operators, types, relations (<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> <programlisting>
=> <userinput>\dd version</userinput> => <userinput>\dd version</userinput>
Object descriptions Object descriptions

26
doc/src/sgml/release.sgml
View File

@ -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"> <appendix id="release">
@ -1196,7 +1196,7 @@ subselect+CASE fixes(Tom)
Add SHLIB_LINK setting for solaris_i386 and solaris_sparc ports(Daren Sefcik) Add SHLIB_LINK setting for solaris_i386 and solaris_sparc ports(Daren Sefcik)
Fixes for CASE in WHERE join clauses(Tom) Fixes for CASE in WHERE join clauses(Tom)
Fix BTScan abort(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) Improve it so that it checks for multi-column constraints(Thomas)
Fix for Win32 making problem with MB enabled(Hiroki Kataoka) Fix for Win32 making problem with MB enabled(Hiroki Kataoka)
Allow BSD yacc and bison to compile pl code(Bruce) Allow BSD yacc and bison to compile pl code(Bruce)
@ -1595,7 +1595,7 @@ Enhancements
------------ ------------
Add "vacuumdb" utility Add "vacuumdb" utility
Speed up libpq by allocating memory better(Tom) Speed up libpq by allocating memory better(Tom)
EXPLAIN all indices used(Tom) EXPLAIN all indexes used(Tom)
Implement CASE, COALESCE, NULLIF expression(Thomas) Implement CASE, COALESCE, NULLIF expression(Thomas)
New pg_dump table output format(Constantin) New pg_dump table output format(Constantin)
Add string min()/max() functions(Thomas) Add string min()/max() functions(Thomas)
@ -2029,14 +2029,14 @@ Allow index use with OR clauses(Bruce)
Allows "SELECT NULL ORDER BY 1;" Allows "SELECT NULL ORDER BY 1;"
Explain VERBOSE prints the plan, and now pretty-prints the plan to Explain VERBOSE prints the plan, and now pretty-prints the plan to
the postmaster log file(Bruce) 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) Allow GROUP BY on functions(David)
New pg_class.relkind for large objects(Bruce) New pg_class.relkind for large objects(Bruce)
New way to send libpq NOTICE messages to a different location(Tom) New way to send libpq NOTICE messages to a different location(Tom)
New \w write command to psql(Bruce) New \w write command to psql(Bruce)
New /contrib/findoidjoins scans oid columns to find join relationships(Bruce) New /contrib/findoidjoins scans oid columns to find join relationships(Bruce)
Allow binary-compatible indices to be considered when checking for valid Allow binary-compatible indexes to be considered when checking for valid
indices for restriction clauses containing a constant(Thomas) Indexes for restriction clauses containing a constant(Thomas)
New ISBN/ISSN code in /contrib/isbn_issn New ISBN/ISSN code in /contrib/isbn_issn
Allow NOT LIKE, IN, NOT IN, BETWEEN, and NOT BETWEEN constraint(Thomas) Allow NOT LIKE, IN, NOT IN, BETWEEN, and NOT BETWEEN constraint(Thomas)
New rewrite system fixes many problems with rules and views(Jan) 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, Add SQL92 "constants" CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP,
CURRENT_USER(Thomas) CURRENT_USER(Thomas)
Modify constraint syntax to be SQL92-compliant(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) Recognize SQL92 syntax for FOREIGN KEY. Throw elog notice(Thomas)
Allow NOT NULL UNIQUE constraint clause (each allowed separately before)(Thomas) Allow NOT NULL UNIQUE constraint clause (each allowed separately before)(Thomas)
Allow Postgres-style casting ("::") of non-constants(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 Support SQL92 syntax for type coercion of literal strings
(e.g. "DATETIME 'now'")(Thomas) (e.g. "DATETIME 'now'")(Thomas)
Add conversions for int2, int4, and OID types to and from text(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 Free memory allocated for an user query inside transaction block after
this query is done, was turned off in <= 6.2.1(Vadim) this query is done, was turned off in <= 6.2.1(Vadim)
New SQL statement CREATE PROCEDURAL LANGUAGE(Jan) New SQL statement CREATE PROCEDURAL LANGUAGE(Jan)
New <productname>Postgres</productname> Procedural Language (PL) backend interface(Jan) New <productname>Postgres</productname> Procedural Language (PL) backend interface(Jan)
Rename pg_dump -H option to -h(Bruce) Rename pg_dump -H option to -h(Bruce)
Add Java support for passwords, European dates(Peter) 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) Add hash functions for datetime and timespan(Thomas)
Time Travel removed(Vadim, Bruce) Time Travel removed(Vadim, Bruce)
Add paging for \d and \z, and fix \i(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 Add pg_description table for info on tables, columns, operators, types, and
aggregates(Bruce) aggregates(Bruce)
Increase 16 char limit on system table/index names to 32 characters(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) Add 'GERMAN' option to SET DATESTYLE(Thomas)
Define an "ISO-style" timespan output format with "hh:mm:ss" fields(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) 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 hash, hashjoin for arrays(Vadim)
fix btree for abstime type(Vadim) fix btree for abstime type(Vadim)
large object fixes(Raymond) 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 rtree for use in inner scan (Vadim)
fix gist for use in inner scan, cleanups (Vadim, Andrea) fix gist for use in inner scan, cleanups (Vadim, Andrea)
avoid unnecessary local buffers allocation (Vadim, Massimo) avoid unnecessary local buffers allocation (Vadim, Massimo)
@ -3816,8 +3816,8 @@ Bug fixes:
* allow the use of \; inside the monitor * allow the use of \; inside the monitor
* the LISTEN/NOTIFY asynchronous notification mechanism now work * the LISTEN/NOTIFY asynchronous notification mechanism now work
* NOTIFY in rule action bodies now work * NOTIFY in rule action bodies now work
* hash indices work, and access methods in general should perform better. * hash indexes work, and access methods in general should perform better.
creation of large btree indices should be much faster. (thanks to Paul creation of large btree indexes should be much faster. (thanks to Paul
Aoki) Aoki)
Other changes and enhancements: Other changes and enhancements:

4
doc/src/sgml/rules.sgml
View File

@ -1869,7 +1869,7 @@ Merge Join
AND software.hostname = computer.hostname; AND software.hostname = computer.hostname;
</ProgramListing> </ProgramListing>
Since there are appropriate indices setup, the planner Since there are appropriate indexes setup, the planner
will create a plan of will create a plan of
<ProgramListing> <ProgramListing>
@ -1919,7 +1919,7 @@ Merge Join
get invoked once for any of the 2000 old computers that get invoked once for any of the 2000 old computers that
have to be deleted and that will result in one index scan have to be deleted and that will result in one index scan
over computer and 2000 index scans for the software. The 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 And it depends on the overall size of the software table if
the rule will still be faster in the seqscan situation. 2000 the rule will still be faster in the seqscan situation. 2000
query executions over the SPI manager take some time, even query executions over the SPI manager take some time, even

6
doc/src/sgml/wal.sgml
View File

@ -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"> <chapter id="wal">
<title>Write-Ahead Logging (<acronym>WAL</acronym>)</title> <title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
@ -18,7 +18,7 @@
is a standard approach to transaction logging. Its detailed is a standard approach to transaction logging. Its detailed
description may be found in most (if not all) books about description may be found in most (if not all) books about
transaction processing. Briefly, <acronym>WAL</acronym>'s central 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 - reside) must be written only after those changes have been logged -
that is, when log records have been flushed to permanent that is, when log records have been flushed to permanent
storage. When we follow this procedure, we do not need to flush storage. When we follow this procedure, we do not need to flush
@ -67,7 +67,7 @@
</listitem> </listitem>
</orderedlist> </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 fixed by additional <function>fsync()</function> calls, but it is
not obvious how to handle the last case without not obvious how to handle the last case without
<acronym>WAL</acronym>; <acronym>WAL</acronym> saves the entire <acronym>WAL</acronym>; <acronym>WAL</acronym> saves the entire

8
doc/src/sgml/xindex.sgml
View File

@ -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 Postgres documentation
--> -->
<chapter id="xindex"> <chapter id="xindex">
<title>Interfacing Extensions To Indices</title> <title>Interfacing Extensions To Indexes</title>
<para> <para>
The procedures described thus far let you define a new type, new The procedures described thus far let you define a new type, new
@ -34,7 +34,7 @@ Postgres documentation
<table tocentry="1"> <table tocentry="1">
<title>Index Schema</title> <title>Index Schema</title>
<titleabbrev>Indices</titleabbrev>
<tgroup cols="2"> <tgroup cols="2">
<thead> <thead>
<row> <row>
@ -118,7 +118,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
example, that the "&lt;=" and "&gt;" operators partition a example, that the "&lt;=" and "&gt;" operators partition a
<acronym>B-tree</acronym>. <productname>Postgres</productname> <acronym>B-tree</acronym>. <productname>Postgres</productname>
uses strategies to express these relationships between 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>
<para> <para>

2
doc/src/sgml/xtypes.sgml
View File

@ -10,7 +10,7 @@
As previously mentioned, there are two kinds of types As previously mentioned, there are two kinds of types
in <productname>Postgres</productname>: base types (defined in a programming language) in <productname>Postgres</productname>: base types (defined in a programming language)
and composite types. 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 be found in <filename>complex.sql</filename> and <filename>complex.c</filename>. Composite examples
are in <filename>funcs.sql</filename>. are in <filename>funcs.sql</filename>.
</para> </para>