{"Entry":{"collection":"storage","key":"storage-hot","name":"Heap-Only Tuples ( HOT )","aliases":[],"metadata":{"aliases":[],"category":"Physical structures","content_hash":"7833c1bc0b75b0b66a9b5673cd12bbbc69e7755b583ddd702ed0f2ff9abb1fdc","imported_at":"2026-09-30T00:40:47.094754+08:00","name":"Heap-Only Tuples ( HOT )","name_zh":"","slug":"storage-hot","summary":"To allow for high concurrency, PostgreSQL uses multiversion concurrency control ( MVCC ) to store rows. However, MVCC 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."}},"Definition":{"Collection":"storage","Key":"storage-hot","SourceDatabase":"center","Version":"18","SourceTable":"storage_structure","SourceKey":"storage-hot","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","Facts":{"comparison_data":{"layouts":[]},"comparison_hash":"27341929154bfb55531f03501322b65af719c5561f3c4ddc9528a14aa4df69b5","description":["To allow for high concurrency, PostgreSQL uses multiversion concurrency control ( MVCC ) to store rows. However, MVCC 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."],"facts":[{"label":"Definition scope","value":"Same-version core physical storage documentation"}],"manual_html":"\u003cdiv class=\"sect1\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch2 class=\"title\"\u003e66.7. Heap-Only Tuples (HOT) \u003c/h2\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eTo allow for high concurrency, \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e uses \u003ca class=\"link\" href=\"/docs/18/mvcc-intro.html\" title=\"13.1. Introduction\"\u003emultiversion concurrency control\u003c/a\u003e (MVCC) to store rows. However, MVCC 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.\u003c/p\u003e\n\u003cp\u003eTo help reduce the overhead of updates, \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e has an optimization called heap-only tuples (HOT). This optimization is possible when:\u003c/p\u003e\n\u003cdiv class=\"itemizedlist\"\u003e\n\u003cul class=\"itemizedlist\"\u003e\n\u003cli class=\"listitem\"\u003e\n\u003cp\u003eThe update does not modify any columns referenced by the table's indexes, not including summarizing indexes. The only summarizing index method in the core \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e distribution is \u003ca class=\"link\" href=\"/docs/18/brin.html\" title=\"65.5. BRIN Indexes\"\u003eBRIN\u003c/a\u003e.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli class=\"listitem\"\u003e\n\u003cp\u003eThere is sufficient free space on the page containing the old row for the updated row.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eIn such cases, heap-only tuples provide two optimizations:\u003c/p\u003e\n\u003cdiv class=\"itemizedlist\"\u003e\n\u003cul class=\"itemizedlist\"\u003e\n\u003cli class=\"listitem\"\u003e\n\u003cp\u003eNew index entries are not needed to represent updated rows, however, summary indexes may still need to be updated.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli class=\"listitem\"\u003e\n\u003cp\u003eWhen a row is updated multiple times, row versions other than the oldest and the newest can be completely removed during normal operation, including \u003ccode class=\"command\"\u003eSELECT\u003c/code\u003es, instead of requiring periodic vacuum operations. (Indexes always refer to the \u003ca class=\"link\" href=\"/docs/18/storage-page-layout.html\" title=\"66.6. Database Page Layout\"\u003epage item identifier\u003c/a\u003e 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.)\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eYou can increase the likelihood of sufficient page space for HOT updates by decreasing a table's \u003ca class=\"link\" href=\"/docs/18/sql-createtable.html#RELOPTION-FILLFACTOR\"\u003e\u003ccode class=\"literal\"\u003efillfactor\u003c/code\u003e\u003c/a\u003e. If you don't, HOT 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 \u003ca class=\"link\" href=\"/docs/18/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW\" title=\"27.2.19. pg_stat_all_tables\"\u003epg_stat_all_tables\u003c/a\u003e allows monitoring of the occurrence of HOT and non-HOT updates.\u003c/p\u003e\n\u003c/div\u003e","manual_path":"/docs/18/storage-hot.html","related":[{"label":"Table AM","url":"/wiki/tableam/?v=18"},{"label":"Storage Parameters","url":"/wiki/relopts/?v=18"}],"release":{"channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sections":[],"signature":"","sources":[{"label":"PostgreSQL 18 English manual","path":"storage-hot.html","sha256":"10b16ef2342681e7c41be6a1bc1e3ea1cb3ba9f592be29dcc941fba269713bfa","url":"/docs/18/storage-hot.html"}],"tables":[]},"ManualEvidence":{"manual_path":"/docs/18/storage-hot.html","release":{"channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sources":[{"label":"PostgreSQL 18 English manual","path":"storage-hot.html","sha256":"10b16ef2342681e7c41be6a1bc1e3ea1cb3ba9f592be29dcc941fba269713bfa","url":"/docs/18/storage-hot.html"}]},"MeasuredEvidence":{}},"Text":{"Collection":"storage","Key":"storage-hot","SourceDatabase":"center","Version":"18","Locale":"en","Title":"Heap-Only Tuples ( HOT )","Summary":"To allow for high concurrency, PostgreSQL uses multiversion concurrency control ( MVCC ) to store rows. However, MVCC 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.","BodyHTML":"\u003cdiv\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch2\u003e66.7. Heap-Only Tuples (HOT) \u003c/h2\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eTo allow for high concurrency, \u003cspan\u003ePostgreSQL\u003c/span\u003e uses \u003ca href=\"/docs/18/mvcc-intro.html\" rel=\"nofollow\"\u003emultiversion concurrency control\u003c/a\u003e (MVCC) to store rows. However, MVCC 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.\u003c/p\u003e\n\u003cp\u003eTo help reduce the overhead of updates, \u003cspan\u003ePostgreSQL\u003c/span\u003e has an optimization called heap-only tuples (HOT). This optimization is possible when:\u003c/p\u003e\n\u003cdiv\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003eThe update does not modify any columns referenced by the table\u0026#39;s indexes, not including summarizing indexes. The only summarizing index method in the core \u003cspan\u003ePostgreSQL\u003c/span\u003e distribution is \u003ca href=\"/docs/18/brin.html\" rel=\"nofollow\"\u003eBRIN\u003c/a\u003e.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eThere is sufficient free space on the page containing the old row for the updated row.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eIn such cases, heap-only tuples provide two optimizations:\u003c/p\u003e\n\u003cdiv\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003eNew index entries are not needed to represent updated rows, however, summary indexes may still need to be updated.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eWhen a row is updated multiple times, row versions other than the oldest and the newest can be completely removed during normal operation, including \u003ccode\u003eSELECT\u003c/code\u003es, instead of requiring periodic vacuum operations. (Indexes always refer to the \u003ca href=\"/docs/18/storage-page-layout.html\" rel=\"nofollow\"\u003epage item identifier\u003c/a\u003e 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.)\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eYou can increase the likelihood of sufficient page space for HOT updates by decreasing a table\u0026#39;s \u003ca href=\"/docs/18/sql-createtable.html#RELOPTION-FILLFACTOR\" rel=\"nofollow\"\u003e\u003ccode\u003efillfactor\u003c/code\u003e\u003c/a\u003e. If you don\u0026#39;t, HOT 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 \u003ca href=\"/docs/18/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW\" rel=\"nofollow\"\u003epg_stat_all_tables\u003c/a\u003e allows monitoring of the occurrence of HOT and non-HOT updates.\u003c/p\u003e\n\u003c/div\u003e","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","ContentHash":"dbcc50433d9d69531088707e71448327b6d365ad573cd862d6a660d840593f01","Payload":{"description":["To allow for high concurrency, PostgreSQL uses multiversion concurrency control ( MVCC ) to store rows. However, MVCC 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."],"manual_html":"\u003cdiv class=\"sect1\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch2 class=\"title\"\u003e66.7. Heap-Only Tuples (HOT) \u003c/h2\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eTo allow for high concurrency, \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e uses \u003ca class=\"link\" href=\"/docs/18/mvcc-intro.html\" title=\"13.1. Introduction\"\u003emultiversion concurrency control\u003c/a\u003e (MVCC) to store rows. However, MVCC 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.\u003c/p\u003e\n\u003cp\u003eTo help reduce the overhead of updates, \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e has an optimization called heap-only tuples (HOT). This optimization is possible when:\u003c/p\u003e\n\u003cdiv class=\"itemizedlist\"\u003e\n\u003cul class=\"itemizedlist\"\u003e\n\u003cli class=\"listitem\"\u003e\n\u003cp\u003eThe update does not modify any columns referenced by the table's indexes, not including summarizing indexes. The only summarizing index method in the core \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e distribution is \u003ca class=\"link\" href=\"/docs/18/brin.html\" title=\"65.5. BRIN Indexes\"\u003eBRIN\u003c/a\u003e.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli class=\"listitem\"\u003e\n\u003cp\u003eThere is sufficient free space on the page containing the old row for the updated row.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eIn such cases, heap-only tuples provide two optimizations:\u003c/p\u003e\n\u003cdiv class=\"itemizedlist\"\u003e\n\u003cul class=\"itemizedlist\"\u003e\n\u003cli class=\"listitem\"\u003e\n\u003cp\u003eNew index entries are not needed to represent updated rows, however, summary indexes may still need to be updated.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli class=\"listitem\"\u003e\n\u003cp\u003eWhen a row is updated multiple times, row versions other than the oldest and the newest can be completely removed during normal operation, including \u003ccode class=\"command\"\u003eSELECT\u003c/code\u003es, instead of requiring periodic vacuum operations. (Indexes always refer to the \u003ca class=\"link\" href=\"/docs/18/storage-page-layout.html\" title=\"66.6. Database Page Layout\"\u003epage item identifier\u003c/a\u003e 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.)\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eYou can increase the likelihood of sufficient page space for HOT updates by decreasing a table's \u003ca class=\"link\" href=\"/docs/18/sql-createtable.html#RELOPTION-FILLFACTOR\"\u003e\u003ccode class=\"literal\"\u003efillfactor\u003c/code\u003e\u003c/a\u003e. If you don't, HOT 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 \u003ca class=\"link\" href=\"/docs/18/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW\" title=\"27.2.19. pg_stat_all_tables\"\u003epg_stat_all_tables\u003c/a\u003e allows monitoring of the occurrence of HOT and non-HOT updates.\u003c/p\u003e\n\u003c/div\u003e","related":[{"label":"Table AM","url":"/wiki/tableam/?v=18"},{"label":"Storage Parameters","url":"/wiki/relopts/?v=18"}],"sections":[],"tables":[]}},"RequestedLocale":"zh-Hans","Fallback":true,"Versions":["11","12","13","14","15","16","17","18","19","20"],"Locales":["en"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}