begriffs open source - ai-pg/blob - full-docs/txt/indexam.txt

   1
   2 Chapter 63. Index Access Method Interface Definition
   3
   4    Table of Contents
   5
   6    63.1. Basic API Structure for Indexes
   7    63.2. Index Access Method Functions
   8    63.3. Index Scanning
   9    63.4. Index Locking Considerations
  10    63.5. Index Uniqueness Checks
  11    63.6. Index Cost Estimation Functions
  12
  13    This chapter defines the interface between the core PostgreSQL system
  14    and index access methods, which manage individual index types. The core
  15    system knows nothing about indexes beyond what is specified here, so it
  16    is possible to develop entirely new index types by writing add-on code.
  17
  18    All indexes in PostgreSQL are what are known technically as secondary
  19    indexes; that is, the index is physically separate from the table file
  20    that it describes. Each index is stored as its own physical relation
  21    and so is described by an entry in the pg_class catalog. The contents
  22    of an index are entirely under the control of its index access method.
  23    In practice, all index access methods divide indexes into standard-size
  24    pages so that they can use the regular storage manager and buffer
  25    manager to access the index contents. (All the existing index access
  26    methods furthermore use the standard page layout described in
  27    Section 66.6, and most use the same format for index tuple headers; but
  28    these decisions are not forced on an access method.)
  29
  30    An index is effectively a mapping from some data key values to tuple
  31    identifiers, or TIDs, of row versions (tuples) in the index's parent
  32    table. A TID consists of a block number and an item number within that
  33    block (see Section 66.6). This is sufficient information to fetch a
  34    particular row version from the table. Indexes are not directly aware
  35    that under MVCC, there might be multiple extant versions of the same
  36    logical row; to an index, each tuple is an independent object that
  37    needs its own index entry. Thus, an update of a row always creates
  38    all-new index entries for the row, even if the key values did not
  39    change. (HOT tuples are an exception to this statement; but indexes do
  40    not deal with those, either.) Index entries for dead tuples are
  41    reclaimed (by vacuuming) when the dead tuples themselves are reclaimed.