--- title: PG Phriday: Burnt TOAST | daily.dev description: Postgres TOAST moves large column values out of the main table heap, and in some cases this can make queries faster, not slower. In a 100k-row benchmark, a... canonical: https://daily.dev/posts/pg-phriday-burnt-toast-1ywdoee5j twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: PG Phriday: Burnt TOAST | daily.dev og:description: Postgres TOAST moves large column values out of the main table heap, and in some cases this can make queries faster, not slower. In a 100k-row benchmark, a... og:url: https://daily.dev/posts/pg-phriday-burnt-toast-1ywdoee5j og:image: https://api.daily.dev/og/posts/1YwDOee5j.png og:image:alt: PG Phriday: Burnt TOAST 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. # PG Phriday: Burnt TOAST **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 14 min read · 0 upvotes · 0 comments ## Summary Postgres TOAST moves large column values out of the main table heap, and in some cases this can make queries faster, not slower. In a 100k-row benchmark, a toasted table was 47MB versus 318MB for a non-toasted version, and counting rows took 26ms versus 91ms. Splitting the bulky column into a separate table shrank the heap further, from 47MB to 5MB, a 9x reduction. Switching compression from pglz to lz4 in Postgres 14+ made compression over 30 times faster, though decompression was about 20% slower. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why is a sequential scan on my PostgreSQL table with a large TEXT or JSON column slower than one without it, even though the table size is bigger? The opposite is often true: toasted tables are usually faster to scan because large values are moved out of the heap into a separate TOAST table, leaving smaller, denser pages. In one benchmark, a 47MB toasted table took 26ms to count rows versus 91ms for a 318MB non-toasted version storing the same data inline with MAIN storage. _Anyone tuning table layout around large columns can compare real TOAST benchmarks like this on daily.dev._ ### How much faster is lz4 compression compared to pglz for TOAST in PostgreSQL 14? lz4 compresses roughly 30 times faster than pglz, based on a test inserting 100,000 rows of 10KB compressible text: pglz took about 52 seconds while lz4 took about 1.8 seconds. Decompression with lz4 was about 20% slower than pglz in the same test. PostgreSQL 14 added the ability to choose compression type per column via the COMPRESSION clause, with pglz as the server default. _Developers picking a toast compression strategy for write-heavy workloads can track benchmarks like this on daily.dev._ ### How can I reduce the size of a PostgreSQL table heap when it has a large JSON or TEXT column slowing down queries that don't even touch that column? Split the large column into a separate table joined by primary key, then expose a view with a LEFT JOIN so existing SELECT * queries still work but unused joins get pruned by the planner. In one case this cut heap size from 47MB to about 5MB, a 9x reduction, since the main table no longer carries TOAST pointers or non-toasted values mixed in. _Engineers restructuring schemas around bulky columns can find patterns like this view-based split on daily.dev._ ## Similar posts on daily.dev - [All Your GUCs in a Row: default\_toast\_compression](https://daily.dev/posts/all-your-gucs-in-a-row-default-toast-compression-qjk0nja2b) · Planet PostgreSQL · 0 upvotes · 0 comments - [Postgres 19 Compression: from pglz to LZ4](https://daily.dev/posts/postgres-19-compression-from-pglz-to-lz4-p8yrk9v3c) · Crunchy Data · 3 upvotes · 0 comments --- Tags: [#postgresql](https://daily.dev/tags/postgresql), [#compression](https://daily.dev/tags/compression) [View this post on daily.dev](https://daily.dev/posts/pg-phriday-burnt-toast-1ywdoee5j) ```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":"PG Phriday: Burnt TOAST","url":"https://daily.dev/posts/pg-phriday-burnt-toast-1ywdoee5j","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/pg-phriday-burnt-toast-1ywdoee5j"},"datePublished":"2026-10-30T18:34:32.797Z","dateModified":"2026-10-30T18:35:05.349Z","description":"Postgres TOAST moves large column values out of the main table heap, and in some cases this can make queries faster, not slower. In a 100k-row benchmark, a...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/6ed0cbee0a67e877ed5a6e500746bed2?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/6ed0cbee0a67e877ed5a6e500746bed2?_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":0,"discussionUrl":"https://daily.dev/posts/pg-phriday-burnt-toast-1ywdoee5j","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"postgresql,compression","timeRequired":"PT14M"} {"@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":"PG Phriday: Burnt TOAST"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/pg-phriday-burnt-toast-1ywdoee5j#faq","mainEntity":[{"@type":"Question","name":"Why is a sequential scan on my PostgreSQL table with a large TEXT or JSON column slower than one without it, even though the table size is bigger?","acceptedAnswer":{"@type":"Answer","text":"The opposite is often true: toasted tables are usually faster to scan because large values are moved out of the heap into a separate TOAST table, leaving smaller, denser pages. In one benchmark, a 47MB toasted table took 26ms to count rows versus 91ms for a 318MB non-toasted version storing the same data inline with MAIN storage. Anyone tuning table layout around large columns can compare real TOAST benchmarks like this on daily.dev."}},{"@type":"Question","name":"How much faster is lz4 compression compared to pglz for TOAST in PostgreSQL 14?","acceptedAnswer":{"@type":"Answer","text":"lz4 compresses roughly 30 times faster than pglz, based on a test inserting 100,000 rows of 10KB compressible text: pglz took about 52 seconds while lz4 took about 1.8 seconds. Decompression with lz4 was about 20% slower than pglz in the same test. PostgreSQL 14 added the ability to choose compression type per column via the COMPRESSION clause, with pglz as the server default. Developers picking a toast compression strategy for write-heavy workloads can track benchmarks like this on daily.dev."}},{"@type":"Question","name":"How can I reduce the size of a PostgreSQL table heap when it has a large JSON or TEXT column slowing down queries that don't even touch that column?","acceptedAnswer":{"@type":"Answer","text":"Split the large column into a separate table joined by primary key, then expose a view with a LEFT JOIN so existing SELECT * queries still work but unused joins get pruned by the planner. In one case this cut heap size from 47MB to about 5MB, a 9x reduction, since the main table no longer carries TOAST pointers or non-toasted values mixed in. Engineers restructuring schemas around bulky columns can find patterns like this view-based split on daily.dev."}}]} ```