+ linkend="locking-indices">.
+
+
+
+
+ The B-tree index is an implementation of Lehman-Yao
+ high-concurrency B-trees. The R-tree index method implements
+ standard R-trees using Guttman's quadratic split algorithm. The
+ hash index is an implementation of Litwin's linear hashing. We
+ mention the algorithms used solely to indicate that all of these
+ access methods are fully dynamic and do not have to be optimized
+ periodically (as is the case with, for example, static hash access
+ methods).
+
+
+
+
+
+
Multi-Column Indices
+
+ An index can be defined on more than one column. For example, if
+ you have a table of this form:
+CREATE TABLE test2 (
+ major int,
+ minor int,
+ name varchar
+);
+
+ (Say, you keep you your /dev
+ directory in a database...) and you frequently make queries like
+SELECT name FROM test2 WHERE major = constant AND minor = constant;
+
+ then it may be appropriate to define an index on the columns
+ major and
+ minor together, e.g.,
+CREATE INDEX test2_mm_idx ON test2 (major, minor);
+
- query optimizer will consider using a hash index whenever
- an indexed attribute is involved in a comparison using
- the = operator.
+ Currently, only the B-tree implementation supports multi-column
+ indices. Up to 16 columns may be specified. (This limit can be
+ a
ltered when building Postgres; see the+ file config.h.)
- Currently, only the btree access method supports multi-column
- indexes. Up to 16 keys may be specified by default (this limit
- can be altered when building Postgres).
+ The query optimizer can use a multi-column index for queries that
+ involve the first
n consecutive columns in
+ the index (when used with appropriate operators), up to the total
+ number of columns specified in the index definition. For example,
+ an index on (a, b, c) can be used in queries
+ involving all of a, b, and
+ c, or in queries involving both
+ a and b, or in queries
+ involving only a, but not in other combinations.
+ (In a query involving a and c
+ the optimizer might choose to use the index for
+ a only and treat c like an
+ ordinary unindexed column.)
- An operator class can be specified for each
- column of an index. The operator class identifies the operators to
- be used by the index for that column. For example, a btree index on
- four-byte integers would use the int4_ops class;
- this operator class includes comparison functions for four-byte
- integers. In practice the default operator class for the field's
- datatype is usually sufficient. The main point of having operator classes
- is that for some datatypes, there could be more than one meaningful
- ordering. For example, we might want to sort a complex-number datatype
- either by absolute value or by real part. We could do this by defining
- two operator classes for the datatype and then selecting the proper
- class when making an index. There are also some operator classes with
- special purposes:
+ Multi-column indexes can only be used if the clauses involving the
+ indexed columns are joined with AND. For instance,
+SELECT name FROM test2 WHERE major = constant OR minor = constant;
+
+ cannot make use of the index test2_mm_idx
+ defined above to look up both columns. (It can be used to look up
+ only the major column, however.)
+
+
+ Multi-column indices 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.
+
+
+
+
+
+
Unique Indices
+
+ Indexes may also be used to enforce uniqueness of a column's value,
+ or the uniqueness of the combined values of more than one column.
+
+CREATE UNIQUE INDEX name ON table (column , ...);
+
+ Only B-tree indices can be declared unique.
+
+
+ When an index is declared unique, multiple table rows with equal
+ indexed values will not be allowed. NULL values are not considered
+ equal.
+
+
+
PostgreSQL automatically creates unique
+ indices 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
+ time, to add a unique constraint. (But a primary key cannot be
+ added after table creation.)
+
+
+
+
+
+
Functional Indices
+
+ 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
+ to data based on the result of function calls.
+
+
+ For example, a common way to do case-insensitive comparisons is to
+ use the lower:
+SELECT * FROM test1 WHERE lower(col1) = 'value';
+
+ In order for that query to be able to use an index, it has to be
+ defined on the result of the lower(column)
+ operation:
+CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
+
+
+
+ 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
+ result) even if the function uses more than one input field; there
+ cannot be multi-column indices that contain function calls.
+
+
+
+ The restrictions mentioned in the previous paragraph can easily be
+ worked around by defining custom functions to use in the index
+ definition that call the desired function(s) internally.
+
+
+
+
+
+
+
Operator Classes
+
+ An index definition may specify an operator
+ class for each column of an index.
+
+CREATE INDEX name ON table (column opclass , ...);
+
+ The operator class identifies the operators to be used by the index
+ for that column. For example, a B-tree index on four-byte integers
+ would use the int4_ops class; this operator
+ class includes comparison functions for four-byte integers. In
+ practice the default operator class for the column's data type is
+ usually sufficient. The main point of having operator classes is
+ that for some data types, there could be more than one meaningful
+ ordering. For example, we might want to sort a complex-number data
+ type either by absolute value or by real part. We could do this by
+ defining two operator classes for the data type and then selecting
+ the proper class when making an index. There are also some
+ operator classes with special purposes:
The operator classes box_ops and
- bigbox_ops both support rtree indices on the
- box datatype.
- The difference between them is that bigbox_ops
- scales box coordinates down, to avoid floating point exceptions from
- doing multiplication, addition, and subtraction on very large
- floating-point coordinates. If the field on which your rectangles lie
- is about 20,000 units square or larger, you should use
+ bigbox_ops both support R-tree indices 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,
+ addition, and subtraction on very large floating point
+ coordinates. If the field on which your rectangles lie is about
+ 20 000 units square or larger, you should use
bigbox_ops.
The following query shows all defined operator classes:
-
SELECT am.amname AS acc_name,
opc.opcname AS ops_name,
opr.oprname AS ops_comp
WHERE amop.amopid = am.oid AND
amop.amopclaid = opc.oid AND
amop.amopopr = opr.oid
- ORDER BY acc_name, ops_name, ops_comp
-
+ ORDER BY acc_name, ops_name, ops_comp;
+
+
- Use DROP INDEX to remove an index.
-
Keys
+>
Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
What's the difference between:
- Is this an alias?
- If PRIMARY KEY is already unique, then why
is there another kind of key named UNIQUE?
- >
+>
However, my application requires that each collection will also have a
unique name. Why? So that a human being who wants to modify a collection
will be able to identify it. It's much harder to know, if you have two
- collections named "Life Science", the the one tagged 24433 is the one you
+ collections named Life Science
, the the one tagged 24433 is the one you
need, and the one tagged 29882 is not.
Moreover, despite being unique, the collection name does not actually
define the collection! For example, if somebody decided to change the name
- of the collection from "Life Science" to "Biology", it will still be the
+ of the collection from Life Science
to Biology
, it will still be the
same collection, only with a different name. As long as the name is unique,
that's OK.
- Are updateable, so long as they are kept unique.
+ Are updatable, so long as they are kept unique.
Thus, you may query a table by any combination of its columns, despite the
fact that you don't have an index on these columns. The indexes are merely
- an implementation
al aid that each
RDBMS offers
+ an implementation aid that each
RDBMS offers
you, in order to cause
commonly used queries to be done more efficiently.
additional measures, such as keeping a key stored in main memory. They will
have a special command, for example
-CREATE MEMSTORE ON <table> COLUMNS <cols>
- >
- (this is not an existing command, just an example).
+>
+CREATE MEMSTORE ON table COLUMNS cols
+>
+ (This is not an existing command, just an example.)
+
Partial Indices
projects / postgresql.git / commitdiff