Add mention of function CREATE INDEX usage.
This commit is contained in:
Bruce Momjian
parent
0c9790e616
commit
50b5d4bf76
|
|
@ -1,5 +1,5 @@
|
|||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.27 2002/03/22 19:20:38 petere Exp $
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.28 2002/04/11 23:20:04 momjian Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
|
|
@ -76,9 +76,10 @@ CREATE [ UNIQUE ] INDEX <replaceable class="parameter">index_name</replaceable>
|
|||
<term><replaceable class="parameter">acc_method</replaceable></term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of the access method to be used for
|
||||
the index. The default access method is <literal>BTREE</literal>.
|
||||
<application>PostgreSQL</application> provides four access methods for indexes:
|
||||
The name of the access method to be used for the index. The
|
||||
default access method is <literal>BTREE</literal>.
|
||||
<application>PostgreSQL</application> provides four access
|
||||
methods for indexes:
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
|
|
@ -225,26 +226,27 @@ ERROR: Cannot create index: 'index_name' already exists.
|
|||
</para>
|
||||
|
||||
<para>
|
||||
In the second syntax shown above, an index is defined
|
||||
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 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.
|
||||
In the second syntax shown above, an index is defined 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
|
||||
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. For example, a functional index on
|
||||
<literal>upper(col)</> would allow the clause
|
||||
<literal>WHERE upper(col) = 'JIM'</> to use an index.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<application>PostgreSQL</application> provides B-tree, R-tree, hash, and GiST access methods for
|
||||
indexes. The B-tree access method is an implementation of
|
||||
Lehman-Yao high-concurrency B-trees. The R-tree access method
|
||||
implements standard R-trees using Guttman's quadratic split algorithm.
|
||||
The hash access method 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).
|
||||
<application>PostgreSQL</application> provides B-tree, R-tree, hash,
|
||||
and GiST access methods for indexes. The B-tree access method is an
|
||||
implementation of Lehman-Yao high-concurrency B-trees. The R-tree
|
||||
access method implements standard R-trees using Guttman's quadratic
|
||||
split algorithm. The hash access method 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).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -338,18 +340,18 @@ ERROR: Cannot create index: 'index_name' already exists.
|
|||
|
||||
<para>
|
||||
An <firstterm>operator class</firstterm> 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 B-tree index on
|
||||
column of an index. 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 <literal>int4_ops</literal> class;
|
||||
this operator class includes comparison functions for four-byte
|
||||
integers. In practice the default operator class for the field's
|
||||
data type is usually sufficient. The main point of having operator classes
|
||||
integers. In practice the default operator class for the field'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:
|
||||
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:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $Header: /cvsroot/pgsql/src/backend/commands/Attic/command.c,v 1.172 2002/04/02 08:51:50 inoue Exp $
|
||||
* $Header: /cvsroot/pgsql/src/backend/commands/Attic/command.c,v 1.173 2002/04/11 23:20:04 momjian Exp $
|
||||
*
|
||||
* NOTES
|
||||
* The PerformAddAttribute() code, like most of the relation
|
||||
|
|
@ -604,10 +604,10 @@ AlterTableAlterColumnDropNotNull(Oid myrelid,
|
|||
elog(ERROR, "ALTER TABLE: Cannot alter system attribute \"%s\"",
|
||||
colName);
|
||||
|
||||
/*
|
||||
/*
|
||||
* Check that the attribute is not in a primary key
|
||||
*/
|
||||
|
||||
|
||||
/* Loop over all indices on the relation */
|
||||
indexoidlist = RelationGetIndexList(rel);
|
||||
|
||||
|
|
@ -986,9 +986,9 @@ AlterTableAlterColumnFlags(Oid myrelid,
|
|||
elog(ERROR, "ALTER TABLE: relation \"%s\" is not a table",
|
||||
RelationGetRelationName(rel));
|
||||
|
||||
/*
|
||||
/*
|
||||
* we allow statistics case for system tables
|
||||
*/
|
||||
*/
|
||||
if (*flagType != 'S' &&
|
||||
!allowSystemTableMods
|
||||
&& IsSystemRelationName(RelationGetRelationName(rel)))
|
||||
|
|
@ -1911,7 +1911,7 @@ LockTableCommand(LockStmt *lockstmt)
|
|||
/*
|
||||
* CREATE SCHEMA
|
||||
*/
|
||||
void
|
||||
void
|
||||
CreateSchemaCommand(CreateSchemaStmt *stmt)
|
||||
{
|
||||
const char *schemaName = stmt->schemaname;
|
||||
|
|
@ -1976,13 +1976,13 @@ CreateSchemaCommand(CreateSchemaStmt *stmt)
|
|||
Node *parsetree = (Node *) lfirst(parsetree_item);
|
||||
List *querytree_list,
|
||||
*querytree_item;
|
||||
|
||||
|
||||
querytree_list = parse_analyze(parsetree, NULL);
|
||||
|
||||
|
||||
foreach(querytree_item, querytree_list)
|
||||
{
|
||||
Query *querytree = (Query *) lfirst(querytree_item);
|
||||
|
||||
|
||||
/* schemas should contain only utility stmts */
|
||||
Assert(querytree->commandType == CMD_UTILITY);
|
||||
/* do this step */
|
||||
|
|
|
|||
Loading…
Reference in New Issue