<!--
-$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">
<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
<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>
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}.
-<!-- $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>
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>
<!--
-$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">
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
</row>
<row>
<entry>pg_index</entry>
- <entry> secondary indices</entry>
+ <entry> secondary indexes</entry>
</row>
<row>
<entry>pg_proc</entry>
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>
<!--
-$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
-->
<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>
</AuthorGroup>
<Date>Transcribed 1998-02-19</Date>
</DocInfo>
-<Title>GiST Indices</Title>
+<Title>GiST Indexes</Title>
<Para>
The information about GIST is at
-<!-- $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>
<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>
</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>
<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>
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
<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>);
<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
</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>
</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>
<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>
</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.
</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>
<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>
<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
</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>
<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>
</sect1>
- <sect1 id="indices-opclass">
+ <sect1 id="indexes-opclass">
<title>Operator Classes</title>
<para>
<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,
<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>
<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>
<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>
<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
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?
</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
<!--
-$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">
</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>
<variablelist>
<varlistentry>
<term>
- GiST and R-Tree indices
+ GiST and R-Tree indexes
</term>
<listitem>
<para>
<varlistentry>
<term>
- Hash indices
+ Hash indexes
</term>
<listitem>
<para>
<varlistentry>
<term>
- Btree indices
+ B-tree indexes
</term>
<listitem>
<para>
</para>
<para>
- Btree indices provide the highest concurrency without deadlock
+ B-tree indexes provide the highest concurrency without deadlock
conditions.
</para>
</listitem>
</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>
<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">
<!--
-$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">
</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
<!--
-$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">
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>
<!--
-$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
-->
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.
<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
<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
<!--
-$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
-->
<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.
-<!-- $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>
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>
<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>
<!--
-$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
-->
<listitem>
<para>
- Retrieve information on tables, including owner, field information, indices.
+ Retrieve information on tables, including owner, field information, indexes.
</para>
</listitem>
</itemizedlist>
<!--
-$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
-->
(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>
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
<!--
-$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">
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)
------------
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)
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)
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)
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)
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)
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)
* 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:
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>
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
-<!-- $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>
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
</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
<!--
-$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
<table tocentry="1">
<title>Index Schema</title>
- <titleabbrev>Indices</titleabbrev>
+
<tgroup cols="2">
<thead>
<row>
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>
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>
projects / postgresql.git / commitdiff