Shaun Thomas: Burnt Toast
Comments on “Shaun Thomas: Burnt Toast”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
In a pgedge.com post, Shaun Thomas revisits a slow Postgres event_log table whose large XML column he had long blamed on TOAST. In a 100k-row JSON test, the toasted table was 47 MB against 318 MB untoasted, and counting rows took 26 ms versus 91 ms, though reading the toasted column itself was slower. Moving the column to a separate table cut the main heap to 5 MB. lz4 compressed over 30 times faster than pglz, with about 20% slower decompression. These are single-author tests on one synthetic workload.
Why it ranked
No. 22 of 59 with a score of 0.58. The panel rated it highest on technical depth (0.91) and new information (0.87), lowest on audience breadth (0.43). Placed No. 22, No. 41 by score alone: the placement terms moved other stories past it.
- AI judgeJudge 2claude-haiku-5-5
- Deep, well-evidenced Postgres internals piece on TOAST with reproducible benchmarks and practical schema advice. Narrow audience of database practitioners, not a major industry development.
- AI judgeJudge 3gpt-5.6-luna
- A detailed, experimentally supported PostgreSQL performance investigation with reproducible SQL, buffer measurements, schema tradeoffs, and compression comparisons. Highly actionable for database-heavy systems, though its relevance is concentrated among PostgreSQL practitioners.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.58total under rubric v2.3
- Significance0.46
- Reader interest0.61
- Audience breadth0.43
- Practical relevance0.72
- Substantiated0.84
- Technical depth0.91
- New information0.87
- Counts against: Promotional0.03
- Counts against: Overclaim0.28
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.51 | 0.30 | 0.58 | 0.46 | 0.28 | +0.24 | +0.111 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.51 | 0.55 | 0.76 | 0.61 | 0.25 | +0.26 | +0.158 |
| Audience breadthHow many people who build technology does it concern? | 0.52 | 0.40 | 0.36 | 0.43 | 0.16 | +0.13 | +0.055 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.78 | 0.60 | 0.78 | 0.72 | 0.18 | +0.22 | +0.159 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.93 | 0.70 | 0.90 | 0.84 | 0.23 | +0.05 | +0.042 |
| Technical depthHow technically substantive is it? | 1.00 | 0.85 | 0.88 | 0.91 | 0.15 | +0.05 | +0.045 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.88 | 0.80 | 0.93 | 0.87 | 0.13 | +0.05 | +0.044 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.04 | 0.03 | 0.01 | 0.03 | 0.03 | −0.19 | −0.005 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.43 | 0.15 | 0.25 | 0.28 | 0.28 | −0.11 | −0.030 |
| Sum of contributions | +0.578 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.578 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-11-01/22/"><img src="https://rubric.hrih.si/badge/2026-11-01/22.svg" alt="Ranked #22 on Rubric, 1 Nov 2026" width="238" height="28"></a>Claim check
Claim check: 6 no source given · 2 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
Couldn’t checkVersion
Postgres TOAST stands for "The Oversized-Attribute Storage Technique" and stores oversized values in a shadow table, split into chunks, with a pointer left in the original row.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “Postgres creates a shadow table for the bulky content, splits it up into chunks, and stores a pointer in the original row”
The source says No passage could be compared.
Source cited by the article: postgresql.org/docs/current/storage-toast.html
Couldn’t checkVersion
Postgres has four valid column storage methods: PLAIN, MAIN, EXTERNAL and EXTENDED, and EXTENDED is the default for TEXT, BYTEA, JSONB and most other variable-length types.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “EXTENDED (x): Anything is fair game. This is the default for TEXT, BYTEA, JSONB, and most other variable-length types”
The source says No passage could be compared.
Source cited by the article: postgresql.org/docs/current/catalog-pg-type.html
No source givenNumber
In the author's test, the toasted event_log table is 47 MB while the non-toasted copy is 318 MB.
The article gives no link or citation for it.
The article says “event_log | non_toast -----------+----------- 47 MB | 318 MB”
The source says No source to compare with.
No source givenNumber
In the author's tests, counting rows took 26ms on the toasted table versus 91ms on the non-toasted one.
The article gives no link or citation for it.
The article says “That’s 26ms vs 91ms”
The source says No source to compare with.
No source givenNumber
After splitting the large column into a separate table, the main heap is 5MB rather than 47MB, a saving of over 9x.
The article gives no link or citation for it.
The article says “The entire heap is now 5MB rather than 47MB, a saving of over 9x”
The source says No source to compare with.
No source givenVersion
As of Postgres 14, the TOAST compression type can be chosen, either the built-in pglz or lz4 if compiled in.
The article gives no link or citation for it.
The article says “As of Postgres 14, it’s even possible to choose the compression type. Stick with the venerable built-in pglz, or use lz4 if it’s been compiled into your binaries”
The source says No source to compare with.
No source givenBenchmark result
In the author's test with 100k rows of 10k compressed values, lz4 was about 20% slower at decompression but over 30 times faster at compression than pglz.
The article gives no link or citation for it.
The article says “lz4 is a bit slower decompressing by about 20% in this case, but is over 30 times faster at compression”
The source says No source to compare with.
No source givenCausal conclusion
The author concludes that the event_log performance problem was caused by the event_data column itself rather than the TOAST system.
The article gives no link or citation for it.
The article says “It turns out that the problem with the event_log table wasn’t necessarily the TOAST system, but the event_data column itself”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 4 pts, not on front page
Recorded for context only, checked 1 Nov 2026, 05:47 UTC. It played no part in the ranking.