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. 高い同時実行性を可能にするために、PostgreSQLはマルチバージョン同時実行制御(MVCC)を使用して行を格納します。 しかし、MVCCには更新クエリに対していくつかの欠点があります。 特に、更新では、テーブルに新しいバージョンの行を追加する必要があります。 また、更新された行ごとに新しいインデックスエントリが必要になる可能性があり、古いバージョンの行とそのインデックスエントリを削除するとコストが高くなります。
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: 更新のオーバーヘッドを減らすために、PostgreSQLにはヒープ専用タプルHOTと呼ばれる最適化があります。 この最適化は以下の場合に可能です。
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>. 更新は、集約インデックスを除き、テーブルのインデックスによって参照される列を変更しません。 コアのPostgreSQL配布で唯一の集約インデックスメソッドはBRINです。
There is sufficient free space on the page containing the old row for the updated row. 古い行を含むページには、更新された行に対して十分な空き領域があります。
In such cases, heap-only tuples provide two optimizations: そのような場合に、ヒープ専用タプルは2つの最適化を提供します。
New index entries are not needed to represent updated rows, however, summary indexes may still need to be updated. 更新された行を表すために新しいインデックスエントリは必要ありませんが、集約インデックスは更新が必要でしょう。
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.)
《機械翻訳》行が複数回更新されると、最古と最新以外の行バージョンは、定期的なVACUUM操作を必要とせずに、通常の操作、SELECTを含めて完全に削除されることがあります。
（インデックスは常に元の行バージョンのページアイテム識別子を参照します。
その行バージョンに関連付けられたタプルデータは削除され、そのアイテム識別子は、依然としていくつかの同時トランザクションに見える可能性のある最古のバージョンを指すリダイレクトに変換されます。
もはや誰にも見えない中間行バージョンは完全に削除され、関連するページアイテム識別子は再利用可能になります。）
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.
テーブルのfillfactorを減らすことで、HOT更新のための十分なページ領域の可能性を高めることができます。
そうしない場合でも、HOT更新は発生します。
なぜなら、新しい行は新しいページや、新しい行バージョンのために十分な空き領域を持つ既存のページに自然に移動するからです。
システムビューpg_stat_all_tablesは、HOTおよび非HOT更新の発生を監視できます。