--- title: Tuning PostgreSQL HOT Updates - A HammerDB Benchmark description: PostgreSQL HOT (Heap Only Tuple) updates can eliminate most vacuum overhead by keeping updated row versions on the same 8 KB page, avoiding index writes... canonical: https://daily.dev/posts/tuning-postgresql-hot-updates---a-hammerdb-benchmark-djhmorrdl twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Tuning PostgreSQL HOT Updates - A HammerDB Benchmark | daily.dev og:description: PostgreSQL HOT (Heap Only Tuple) updates can eliminate most vacuum overhead by keeping updated row versions on the same 8 KB page, avoiding index writes... og:url: https://daily.dev/posts/tuning-postgresql-hot-updates---a-hammerdb-benchmark-djhmorrdl og:image: https://api.daily.dev/og/posts/DJhMoRrdL.png og:image:alt: Tuning PostgreSQL HOT Updates - A HammerDB Benchmark og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Tuning PostgreSQL HOT Updates - A HammerDB Benchmark **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 20 min read · 7 upvotes · 1 comments ## Summary PostgreSQL HOT (Heap Only Tuple) updates can eliminate most vacuum overhead by keeping updated row versions on the same 8 KB page, avoiding index writes entirely. The key tuning lever is the fillfactor setting, which reserves free space on each page for future updates. A rigorous HammerDB TPROC-C benchmark across three dataset sizes (2 GB, 3.9 GB, 10 GB) shows that correctly applying per-table fillfactor values yields 13.5–47.8% throughput gains, with the largest gains when data fits in memory. Critically, the analysis reveals that fillfactor should not be applied uniformly: only 4 of 9 TPC-C tables benefited, and the right value differs per table. Tables with high update frequency per row (like warehouse) are self-healing via opportunistic pruning and need no adjustment. The real diagnostic metric is n_tup_newpage_upd — the count of updates that couldn't stay on their page. Beyond throughput, the tuned configuration reduced vacuum time by up to 7x and eliminated table bloat on the stock table entirely. The article also warns that a poor HOT ratio is usually a schema problem (indexed mutable columns) that no fillfactor setting can fix. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What does the pg_stat_user_tables.n_tup_newpage_upd column measure in PostgreSQL? It counts updates that could not stay on their original page, meaning the row version had to move and every index on the table needed a new entry. This is the direct symptom that fillfactor tuning addresses: if the value is zero, HOT updates are already succeeding and fillfactor has nothing left to fix for that table. _daily.dev surfaces practical postgres tuning findings like this for engineers debugging update performance._ ### How much does raising fillfactor from 100 to 90 improve HOT update rates on TPC-C style tables in PostgreSQL 18.4? In a HammerDB TPROC-C benchmark on PostgreSQL 18.4, moving order_line, orders, stock, and customer from fillfactor 100 to a tuned value (80-90) raised HOT ratios from roughly 68-91 percent up to 98.6-100 percent depending on table and dataset size. Throughput gains ranged from 47.8 percent at a small in-memory dataset down to 13.5 percent once the dataset exceeded total RAM, and vacuum time on the stock table dropped up to 7x. _engineers deciding how to configure fillfactor for their own workload can track benchmarks like this on daily.dev._ ### Why did the warehouse and district tables in TPC-C show no benefit from fillfactor tuning despite being updated constantly? Both tables were already measured at 99.95 percent and 99.6 percent HOT respectively at the default fillfactor because HOT pruning is opportunistic and fires on page access, so pages hammered by extremely frequent updates keep reclaiming their own space continuously. The rule that emerged is that fillfactor helps insert-then-update tables, not simply busy tables; warehouse takes over 120,000 updates per row and fails almost none of them. _anyone tuning postgres schemas benefits from seeing measured counterexamples like this before applying blanket rules, which daily.dev helps surface._ ## Community discussion Top comments from developers on daily.dev. **@trevorsuna** · 0 upvotes > The per-table result matters more than a headline fillfactor value. Watching n_tup_newpage_upd alongside vacuum time gives teams a practical way to target the tables that need space, while avoiding a blanket setting that wastes cache and storage. ## Similar posts on daily.dev - [Fix PostgreSQL Index Bloat & Buffer Cache Issues](https://daily.dev/posts/fix-postgresql-index-bloat-buffer-cache-issues-ah4j9ec7v) · SitePoint · 2 upvotes · 0 comments - [My queries to monitor autovacuum](https://daily.dev/posts/my-queries-to-monitor-autovacuum-vscqbjwpm) · CYBERTEC PostgreSQL · 0 upvotes · 0 comments --- Tags: [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/tuning-postgresql-hot-updates---a-hammerdb-benchmark-djhmorrdl) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Tuning PostgreSQL HOT Updates - A HammerDB Benchmark","url":"https://daily.dev/posts/tuning-postgresql-hot-updates---a-hammerdb-benchmark-djhmorrdl","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/tuning-postgresql-hot-updates---a-hammerdb-benchmark-djhmorrdl"},"datePublished":"2026-08-05T09:18:21.551Z","dateModified":"2026-09-14T08:32:05.310Z","description":"PostgreSQL HOT (Heap Only Tuple) updates can eliminate most vacuum overhead by keeping updated row versions on the same 8 KB page, avoiding index writes...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b1ac3aee686ce67b95bffa41229d3820?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b1ac3aee686ce67b95bffa41229d3820?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/tuning-postgresql-hot-updates---a-hammerdb-benchmark-djhmorrdl","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":7},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"postgresql","timeRequired":"PT20M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"Tuning PostgreSQL HOT Updates - A HammerDB Benchmark"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/tuning-postgresql-hot-updates---a-hammerdb-benchmark-djhmorrdl","comment":[{"@type":"Comment","text":"The per-table result matters more than a headline fillfactor value. Watching n_tup_newpage_upd alongside vacuum time gives teams a practical way to target the tables that need space, while avoiding a blanket setting that wastes cache and storage.","datePublished":"2026-08-06T02:40:27.563Z","url":"https://daily.dev/posts/DJhMoRrdL#c-ABzaUY6fV","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/tuning-postgresql-hot-updates---a-hammerdb-benchmark-djhmorrdl#faq","mainEntity":[{"@type":"Question","name":"What does the pg_stat_user_tables.n_tup_newpage_upd column measure in PostgreSQL?","acceptedAnswer":{"@type":"Answer","text":"It counts updates that could not stay on their original page, meaning the row version had to move and every index on the table needed a new entry. This is the direct symptom that fillfactor tuning addresses: if the value is zero, HOT updates are already succeeding and fillfactor has nothing left to fix for that table. daily.dev surfaces practical postgres tuning findings like this for engineers debugging update performance."}},{"@type":"Question","name":"How much does raising fillfactor from 100 to 90 improve HOT update rates on TPC-C style tables in PostgreSQL 18.4?","acceptedAnswer":{"@type":"Answer","text":"In a HammerDB TPROC-C benchmark on PostgreSQL 18.4, moving order_line, orders, stock, and customer from fillfactor 100 to a tuned value (80-90) raised HOT ratios from roughly 68-91 percent up to 98.6-100 percent depending on table and dataset size. Throughput gains ranged from 47.8 percent at a small in-memory dataset down to 13.5 percent once the dataset exceeded total RAM, and vacuum time on the stock table dropped up to 7x. engineers deciding how to configure fillfactor for their own workload can track benchmarks like this on daily.dev."}},{"@type":"Question","name":"Why did the warehouse and district tables in TPC-C show no benefit from fillfactor tuning despite being updated constantly?","acceptedAnswer":{"@type":"Answer","text":"Both tables were already measured at 99.95 percent and 99.6 percent HOT respectively at the default fillfactor because HOT pruning is opportunistic and fires on page access, so pages hammered by extremely frequent updates keep reclaiming their own space continuously. The rule that emerged is that fillfactor helps insert-then-update tables, not simply busy tables; warehouse takes over 120,000 updates per row and fails almost none of them. anyone tuning postgres schemas benefits from seeing measured counterexamples like this before applying blanket rules, which daily.dev helps surface."}}]} ```