The catalog <structname>pg_am</structname> stores information about

relation access methods. There is one row for each access method supported

by the system.

Currently, onlytable and indexes have access methods. The requirements for table

Currently, onlytables and indexes have access methods. The requirements for table

and index access methods are discussed in detail in <xref linkend="tableam"/> and

<xref linkend="indexam"/> respectively.

</para>

</para>

<para>

In contrast to <command>CREATE TABLE AS</command> <command>SELECT

In contrast to <command>CREATE TABLE AS</command>, <command>SELECT

INTO</command> does not allow to specify properties like a table's access

method with <xref linkend="sql-createtable-method" /> or the table's

tablespace with <xref linkend="sql-createtable-tablespace" />. Use <xref

linkend="sql-createtableas"/> if necessary. Therefore the default table

linkend="sql-createtableas"/> if necessary. Therefore, the default table

access method is chosen for the new table. See <xref

linkend="guc-default-table-access-method"/> for more information.

</para>

</para>

<para>

Note that the following sections describe theway the builtin

Note that the following sections describe thebehavior of the builtin

<literal>heap</literal> <link linkend="tableam">table access method</link>,

and the builtin <link linkend="indexam">index access methods</link> work. Due

to the extensible nature of <productname>PostgreSQL</productname> other types

ofaccessmethod might worksimilar or not.

and the builtin <link linkend="indexam">index access methods</link>. Due

to the extensible nature of <productname>PostgreSQL</productname>, other

accessmethods might workdifferently.

</para>

<para>

This section provides an overview of the page format used within

<productname>PostgreSQL</productname> tables and indexes.<footnote>

<para>

Actually,neither table nor index access methods neednotuse this page

format. All the existingindex methods do use this basic format, but the

this format.

Actually,use of this page format isnotrequired for either table or

indexaccessmethods. The <literal>heap</literal> table access method

the item layout rules.

</para>

</footnote>

Sequences and <acronym>TOAST</acronym> tables are formatted just like a regular table.

callbacks and their behavior is defined in the

<structname>TableAmRoutine</structname> structure (with comments inside the

struct defining the requirements for callbacks). Most callbacks have

wrapper functions, which are documentedfor the point of view of a user,

rather than an implementor, of the table access method. For details,

wrapper functions, which are documentedfrom the point of view of a user

(rather than an implementor) of the table access method. For details,

please refer to the <ulink url="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/access/tableam.h;hb=HEAD">

<filename>src/include/access/tableam.h</filename></ulink> file.

</para>

<para>

To implementa access method, an implementor will typically need to

implementa AMspecific type of tuple table slot (see

To implementan access method, an implementor will typically need to

implementan AM-specific type of tuple table slot (see

<ulink url="https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/executor/tuptable.h;hb=HEAD">

<filename>src/include/executor/tuptable.h</filename></ulink>) which allows

<filename>src/include/executor/tuptable.h</filename></ulink>), which allows

code outside the access method to hold references to tuples of the AM, and

to access the columns of the tuple.

</para>

<para>

Currently thetheway an AM actually stores data is fairly

unconstrained. It is e.g. possibleto use postgres' shared buffer cache,

but not required.In caseshared buffers areused, it likely makesto

postgres' standard page layout described in <xref

linkend="storage-page-layout"/>.

Currently, the way an AM actually stores data is fairly unconstrained. For

example, it's possible, but not required,to use postgres' shared buffer

cache.In caseit isused, it likely makessense to use

<productname>PostgreSQL</productname>'s standard page layoutasdescribed in

<xreflinkend="storage-page-layout"/>.

</para>

<para>

One fairly large constraint of the table access method API is that,

currently, if the AM wants to support modifications and/or indexes, it is

necessarythat each tuplehas a tuple identifier (<acronym>TID</acronym>)

necessaryfor each tupleto have a tuple identifier (<acronym>TID</acronym>)

consisting of a block number and an item number (see also <xref

linkend="storage-page-layout"/>). It is not strictly necessary that the

sub-parts of <acronym>TIDs</acronym> have the same meaning they e.g. have

</para>

<para>

For crash safety an AM can use postgres' <link

linkend="wal"><acronym>WAL</acronym></link>, or a custom approach can be

implemented. If <acronym>WAL</acronym> is chosen, either <link

linkend="generic-wal">Generic WAL Records</link> can be used &mdash; which

implies higher WAL volume but is easy, or a new type of

<acronym>WAL</acronym> records can be implemented &mdash; but that

currently requires modifications of core code (namely modifying

For crash safety, an AM can use postgres' <link

linkend="wal"><acronym>WAL</acronym></link>, or a custom implementation.

If <acronym>WAL</acronym> is chosen, either <link

linkend="generic-wal">Generic WAL Records</link> can be used,

or a new type of <acronym>WAL</acronym> records can be implemented.

Generic WAL Records are easy, but imply higher WAL volume.

Implementation of a new type of WAL record

currently requires modifications to core code (specifically,

<filename>src/include/access/rmgrlist.h</filename>).

</para>

<para>

Any developer of a new <literal>table access method</literal> can refer to

the existing <literal>heap</literal> implementation present in

<filename>src/backend/heap/heapam_handler.c</filename> formoredetails of

how it is implemented.

<filename>src/backend/heap/heapam_handler.c</filename> for details of

its implementation.

</para>

</chapter>