- linkend="locking-indices">.
+ hash ind
exes require coarser locks; see
+ linkend="locking-indexes">.
- ices-multicolumn">
-
Multi-Column Ind<span class="marked">ic</span>es
+ exes-multicolumn">
+
Multi-Column Ind<span class="marked">ex</span>es
- ices-multicolumn">
+ exes-multicolumn">
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
Postgres; see the
file config.h.)
- 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.
- ices-unique">
-
Unique Ind<span class="marked">ic</span>es
+ exes-unique">
+
Unique Ind<span class="marked">ex</span>es
- ices-unique">
+ exes-unique">
unique
CREATE UNIQUE INDEX name ON table (column , ...);
- Only B-tree indices can be declared unique.
+ Only B-tree indexes can be declared unique.
PostgreSQL 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
- ices-functional">
-
Functional Ind<span class="marked">ic</span>es
+ exes-functional">
+
Functional Ind<span class="marked">ex</span>es
- ices-functional">
+ exes-functional">
on functions
For a functional index, 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.
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.
- ices-opclass">
+ exes-opclass">
Operator Classes
The operator classes box_ops and
- bigbox_ops both support R-tree indices on the
+ bigbox_ops both support R-tree indexes on the
box data type. The difference between them is
that bigbox_ops scales box coordinates down,
to avoid floating point exceptions from doing multiplication,
As for why no non-unique keys are defined explicitly in standard
- must understand that indices are implementation-dependent.
+ must understand that indexes are implementation-dependent.
define the implementation, merely the relations between data in the
database.
Postgres does allow
- non-unique indices, but indices
+ non-unique indexes, but indexes
used to enforce
SQL keys are always unique.
- be it an index, my imaginary MEMSTORE command, or an intelligent
- 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).
- Partial Indices
+ Partial Indexes
partial
Note
- Partial indices are not currently supported by
+ Partial indexes are not currently supported by
PostgreSQL, but they were once supported
by its predecessor
Postgres, and much
of the code is still there. We hope to revive support for this
A partial index
is an index built over a subset of a table; the subset is defined by
- supported partial indices with arbitrary
+ supported partial indexes with arbitrary
predicates. I believe IBM's
DB2- for AS/400 supports partial indices
+ for AS/400 supports partial indexes
using single-clause predicates.
- 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?
- 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
- ices">
-
Locking and Ind<span class="marked">ic</span>es
+ exes">
+
Locking and Ind<span class="marked">ex</span>es
- GiST and R-Tree indices
+ GiST and R-Tree indexes
- Hash indices
+ Hash indexes
- Btree indices
+ B-tree indexes
- Btree indices provide the highest concurrency without deadlock
+ B-tree indexes provide the highest concurrency without deadlock
conditions.
- In short, btree indices are the recommended index type for concurrent
+ In short, B-tree indexes are the recommended index type for concurrent
applications.
The following table shows how pages in both normal
Postgres tables
(e.g., a B-tree index) are structured.
- ices">
-
Remove Ind<span class="marked">ic</span>es
+ exes">
+
Remove Ind<span class="marked">ex</span>es
If you are loading a freshly created table, the fastest way is to
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.
Advantages of Using PL/pgSQL
on the result of a user-specified function
func_name applied
to one or more columns of a single table.
- These functional indices
+ These functional indexes
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.
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
The operator classes box_ops and
- bigbox_ops both support rtree indices on the
+ bigbox_ops both support rtree indexes on the
box data type.
The difference between them is that bigbox_ops
scales box coordinates down, to avoid floating-point exceptions from
pg_dump
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.
-
+
or even to reorder the items prior to being restored. The archive files are designed
to be portable across architectures. pg_dump 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.
Restore items in modified OID order. By default pg_dump will dump items in an order convenient
to pg_dump, 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.
- Retrieve information on tables, including owner, field information, indices.
+ Retrieve information on tables, including owner, field information, indexes.
(which could be a table, view, index, or sequence),
their types, and any special attributes such as NOT NULL
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.
Shows the descriptions of object
(which can be a regular expression), or of all objects if no argument is given.
(Object
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:
=> \dd version
Object descriptions
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
Postgres 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;
- Since there are appropriate indices setup, the planner
+ Since there are appropriate indexes setup, the planner
will create a plan of
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
-
+
Write-Ahead Logging (<acronym>WAL</acronym>)
is a standard approach to transaction logging. Its detailed
description may be found in most (if not all) books about
transaction processing. Briefly,
WAL'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
- 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 fsync() calls, but it is
not obvious how to handle the last case without
WAL;
WAL saves the entire
-
Interfacing Extensions To Ind<span class="marked">ic</span>es
+
Interfacing Extensions To Ind<span class="marked">ex</span>es
The procedures described thus far let you define a new type, new
Index Schema
- Indices
+
|
example, that the "<=" and ">" operators partition a
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.
As previously mentioned, there are two kinds of types
in
Postgres: 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 complex.sql and complex.c. Composite examples
are in funcs.sql.
projects / postgresql.git / commitdiff