information, see
     <xref linkend="sql-createtable"/>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-tablespace">
   <glossterm>Tablespace</glossterm>
   <glossdef>
    <para>
     A named location on the server file system.
     All <glossterm linkend="glossary-sql-object">SQL objects</glossterm>
     which require storage beyond their definition in the
     <glossterm linkend="glossary-system-catalog">system catalog</glossterm>
     must belong to a single tablespace.
     Initially, a database cluster contains a single usable tablespace which is
     used as the default for all SQL objects, called <literal>pg_default</literal>.
    </para>
    <para>
     For more information, see
     <xref linkend="manage-ag-tablespaces"/>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-temporary-table">
   <glossterm>Temporary table</glossterm>
   <glossdef>
    <para>
     <glossterm linkend="glossary-table">Tables</glossterm> that exist either
     for the lifetime of a
     <glossterm linkend="glossary-session">session</glossterm> or a
     <glossterm linkend="glossary-transaction">transaction</glossterm>, as
     specified at the time of creation.
     The data in them is not visible to other sessions, and is not
     <glossterm linkend="glossary-logged">logged</glossterm>.
     Temporary tables are often used to store intermediate data for a
     multi-step operation.
    </para>
    <para>
     For more information, see
     <xref linkend="sql-createtable"/>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-toast">
   <glossterm>TOAST</glossterm>
   <glossdef>
    <para>
     A mechanism by which large attributes of table rows are split and
     stored in a secondary table, called the <firstterm>TOAST table</firstterm>.
     Each relation with large attributes has its own TOAST table.
    </para>
    <para>
     For more information, see
     <xref linkend="storage-toast" />.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-transaction">
   <glossterm>Transaction</glossterm>
   <glossdef>
    <para>
     A combination of commands that must act as a single
     <glossterm linkend="glossary-atomic">atomic</glossterm> command: they all
     succeed or all fail as a single unit, and their effects are not visible to
     other <glossterm linkend="glossary-session">sessions</glossterm> until
     the transaction is complete, and possibly even later, depending on the
     isolation level.
    </para>
    <para>
     For more information, see
     <xref linkend="transaction-iso"/>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-xid">
   <glossterm>Transaction ID</glossterm>
   <glossdef>
    <para>
     The numerical, unique, sequentially-assigned identifier that each
     transaction receives when it first causes a database modification.
     Frequently abbreviated as <firstterm>xid</firstterm>.
     When stored on disk, xids are only 32-bits wide, so only
     approximately four billion write transaction IDs can be generated;
     to permit the system to run for longer than that,
     <firstterm>epochs</firstterm> are used, also 32 bits wide.
     When the counter reaches the maximum xid value, it starts over at
     <literal>3</literal> (values under that are reserved) and the
     epoch value is incremented by one.
     In some contexts, the epoch and xid values are
     considered together as a single 64-bit value;  see <xref
     linkend="transaction-id"/> for more details.
    </para>
    <para>
     For more information, see
     <xref linkend="datatype-oid"/>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-tps">
   <glossterm>Transactions per second (TPS)</glossterm>
   <glossdef>
    <para>
     Average number of transactions that are executed per second,
     totaled across all sessions active for a measured run.
     This is used as a measure of the performance characteristics of
     an