Home • Explore • Blog • CI
☰



postgresql
15th chunk of `doc/src/sgml/storage.sgml`
9ad04baaeb5dbbb751f6ecf759dabe04b5077e83f25b5e3500000001000008ff
 <row>
   <entry>t_hoff</entry>
   <entry>uint8</entry>
   <entry>1 byte</entry>
   <entry>offset to user data</entry>
  </row>
 </tbody>
 </tgroup>
 </table>

 <para>
   All the details can be found in
   <filename>src/include/access/htup_details.h</filename>.
 </para>

 <para>

  Interpreting the actual data can only be done with information obtained
  from other tables, mostly <structname>pg_attribute</structname>. The
  key values needed to identify field locations are
  <structfield>attlen</structfield> and <structfield>attalign</structfield>.
  There is no way to directly get a
  particular attribute, except when there are only fixed width fields and no
  null values. All this trickery is wrapped up in the functions
  <firstterm>heap_getattr</firstterm>, <firstterm>fastgetattr</firstterm>
  and <firstterm>heap_getsysattr</firstterm>.

 </para>
 <para>

  To read the data you need to examine each attribute in turn. First check
  whether the field is NULL according to the null bitmap. If it is, go to
  the next. Then make sure you have the right alignment.  If the field is a
  fixed width field, then all the bytes are simply placed. If it's a
  variable length field (attlen = -1) then it's a bit more complicated.
  All variable-length data types share the common header structure
  <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
Title: HeapTuple Data Interpretation, Variable Length Fields, and Heap-Only Tuples (HOT)
Summary
This section describes how to interpret HeapTuple data by examining each attribute, checking for NULL values using the null bitmap, and ensuring proper alignment. It explains the structure of variable-length fields, which use struct varlena to store total length and flag bits, indicating whether the data is inline or in a TOAST table. It then introduces Heap-Only Tuples (HOT) as an optimization to reduce the overhead of MVCC updates by minimizing index updates and tuple versions.