| PostgreSQL 7.4.16 Documentation | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 43. System Catalogs | Fast Forward | Next |
The catalog pg_am stores information about index access methods. There is one row for each index access method supported by the system.
Table 43-3. pg_am Columns
| Name | Type | References | Description |
|---|---|---|---|
| amname | name | Name of the access method | |
| amowner | int4 | pg_shadow.usesysid | User ID of the owner (currently not used) |
| amstrategies | int2 | Number of operator strategies for this access method | |
| amsupport | int2 | Number of support routines for this access method | |
| amorderstrategy | int2 | Zero if the index offers no sort order, otherwise the strategy number of the strategy operator that describes the sort order | |
| amcanunique | bool | Does the access method support unique indexes? | |
| amcanmulticol | bool | Does the access method support multicolumn indexes? | |
| amindexnulls | bool | Does the access method support null index entries? | |
| amconcurrent | bool | Does the access method support concurrent updates? | |
| amgettuple | regproc | pg_proc.oid | "Next valid tuple" function |
| aminsert | regproc | pg_proc.oid | "Insert this tuple" function |
| ambeginscan | regproc | pg_proc.oid | "Start new scan" function |
| amrescan | regproc | pg_proc.oid | "Restart this scan" function |
| amendscan | regproc | pg_proc.oid | "End this scan" function |
| ammarkpos | regproc | pg_proc.oid | "Mark current scan position" function |
| amrestrpos | regproc | pg_proc.oid | "Restore marked scan position" function |
| ambuild | regproc | pg_proc.oid | "Build new index" function |
| ambulkdelete | regproc | pg_proc.oid | Bulk-delete function |
| amvacuumcleanup | regproc | pg_proc.oid | Post-VACUUM cleanup function |
| amcostestimate | regproc | pg_proc.oid | Function to estimate cost of an index scan |
An index access method that supports multiple columns (has amcanmulticol true) must support indexing null values in columns after the first, because the planner will assume the index can be used for queries on just the first column(s). For example, consider an index on (a,b) and a query with WHERE a = 4. The system will assume the index can be used to scan for rows with a = 4, which is wrong if the index omits rows where b is null. It is, however, OK to omit rows where the first indexed column is null. (GiST currently does so.) amindexnulls should be set true only if the index access method indexes all rows, including arbitrary combinations of null values.
No comments could be found for this page.
Please use this form to add your own comments regarding your experience with particular features of PostgreSQL, clarifications of the documentation, or hints for other users. Please note, this is not a support forum, and your IP address will be logged. If you have a question or need help, please see the faq, try a mailing list, or join us on IRC. Note that submissions containing URLs or other keywords commonly found in 'spam' comments may be silently discarded. Please contact the webmaster if you think this is happening to you in error.
In order to submit a comment, you must have a community account.
* denotes required field