<type>struct varlena</type>, which includes the total length of the stored
  value and some flag bits.  Depending on the flags, the data can be either
  inline or in a <acronym>TOAST</acronym> table;
  it might be compressed, too (see <xref linkend="storage-toast"/>).

 </para>
 </sect2>
</sect1>

<sect1 id="storage-hot">

 <title>Heap-Only Tuples (<acronym>HOT</acronym>)</title>

 <para>
  To allow for high concurrency, <productname>PostgreSQL</productname>
  uses <link linkend="mvcc-intro">multiversion concurrency
  control</link> (<acronym>MVCC</acronym>) to store rows.  However,
  <acronym>MVCC</acronym> has some downsides for update queries.
  Specifically, updates require new versions of rows to be added to
  tables.  This can also require new index entries for each updated row,
  and removal of old versions of rows and their index entries can be
  expensive.
 </para>

 <para>
  To help reduce the overhead of updates,
  <productname>PostgreSQL</productname> has an optimization called
  heap-only tuples (<acronym>HOT</acronym>).  This optimization is
  possible when:

  <itemizedlist>
   <listitem>
    <para>
     The update does not modify any columns referenced by the table's indexes,
     not including summarizing indexes.  The only summarizing index method in
     the core <productname>PostgreSQL</productname> distribution is <link
     linkend="brin">BRIN</link>.
     </para>
   </listitem>
   <listitem>
    <para>
     There is sufficient free space on the page containing the old row
     for the updated row.
    </para>
   </listitem>
  </itemizedlist>

  In such cases, heap-only tuples provide two optimizations:

  <itemizedlist>
   <listitem>
    <para>
     New index entries are not needed to represent updated rows, however,
     summary indexes may still need to be updated.
    </para>
   </listitem>
   <listitem>
    <para>
     When a row is updated multiple times, row versions other than the oldest
     and the newest can be completely removed during normal operation,
     including <command>SELECT</command>s, instead of requiring periodic vacuum
     operations.  (Indexes always refer to the
     <link linkend="storage-page-layout">page item identifier</link> of the
     original row version. The tuple data associated with that row version
     is removed, and its item identifier is converted to a redirect that
     points to the oldest version that may still be visible to some concurrent
     transaction. Intermediate row versions that are no longer visible to
     anyone are completely removed, and the associated page item identifiers
     are made available for reuse.)
    </para>
   </listitem>
  </itemizedlist>
 </para>

 <para>
  You can increase the likelihood of sufficient page space for
  <acronym>HOT</acronym> updates by decreasing a table's <link
  linkend="reloption-fillfactor"><literal>fillfactor</literal></link>.  If you
  don't, <acronym>HOT</acronym> updates will still happen because new rows
  will naturally migrate to new pages and existing pages with sufficient free
  space for new row versions.  The system view <link
  linkend="monitoring-pg-stat-all-tables-view">pg_stat_all_tables</link>
  allows monitoring of the occurrence of HOT and non-HOT updates.
 </para>
</sect1>

</chapter>