Supported Versions: Current (16) / 15 / 14 / 13 / 12
Development Versions: devel
Unsupported versions: 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1 / 8.0 / 7.4 / 7.3
This documentation is for an unsupported version of PostgreSQL.
You may want to view the same page for the current version, or one of the other supported versions listed above instead.

43.3. pg_am

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.