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 instance.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-trigger">
   <glossterm>Trigger</glossterm>
   <glossdef>
    <para>
     A <glossterm linkend="glossary-function">function</glossterm> which can
     be defined to execute whenever a certain operation (<command>INSERT</command>,
     <command>UPDATE</command>, <command>DELETE</command>,
     <command>TRUNCATE</command>) is applied to a
     <glossterm linkend="glossary-relation">relation</glossterm>.
     A trigger executes within the same
     <glossterm linkend="glossary-transaction">transaction</glossterm> as the
     statement which invoked it, and if the function fails, then the invoking
     statement also fails.
    </para>
    <para>
     For more information, see
     <xref linkend="sql-createtrigger"/>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-tuple">
   <glossterm>Tuple</glossterm>
   <glossdef>
    <para>
     A collection of <glossterm linkend="glossary-attribute">attributes</glossterm>
     in a fixed order.
     That order may be defined by the <glossterm linkend="glossary-table">table</glossterm>
     (or other <glossterm linkend="glossary-relation">relation</glossterm>)
     where the tuple is contained, in which case the tuple is often called a
     <firstterm>row</firstterm>.  It may also be defined by the structure of a
     result set, in which case it is sometimes called a <firstterm>record</firstterm>.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-unique-constraint">
   <glossterm>Unique constraint</glossterm>
   <glossdef>
    <para>
     A type of <glossterm linkend="glossary-constraint">constraint</glossterm>
     defined on a <glossterm linkend="glossary-relation">relation</glossterm>
     which restricts the values allowed in one or a combination of columns
     so that each value or combination of values can only appear once in the
     relation &mdash; that is, no other row in the relation contains values
     that are equal to those.
    </para>
    <para>
     Because <glossterm linkend="glossary-null">null values</glossterm> are
     not considered equal to each other, multiple rows with null values are
     allowed to exist without violating the unique constraint.
    </para>
   </glossdef>
  </glossentry>

  <glossentry id="glossary-unlogged">
   <glossterm>Unlogged</glossterm>
   <glossdef>
    <para>
     The property of certain <glossterm linkend="glossary-relation">relations</glossterm>
     that the changes to them are not reflected in the
     <glossterm linkend="glossary-wal">WAL</glossterm>.
     This disables replication and crash recovery for these relations.
    </para>
    <para>
     The primary use of unlogged tables is for storing
     transient work data that must be shared across processes.
    </para>
    <para>
     <glossterm linkend="glossary-temporary-table">Temporary tables</glossterm>
     are always unlogged.
    </para>
   </glossdef>
  </glossentry>