How to find 300% of a lost performance in a mature database code
Comments on “How to find 300% of a lost performance in a mature database code”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
Alessandro Vetere reports that a MariaDB 10.5 change left InnoDB in-memory workloads paying for LRU promotion, because the freed-page clock starts ticking early and turns on a buf_pool.mutex acquisition on nearly every page access.
Why it ranked
No. 21 of 111 with a score of 0.62. The panel rated it highest on technical depth (0.95) and new information (0.93), lowest on audience breadth (0.44). The judges disagreed most on overclaim (spread 0.41), so the story is marked contested. Placed No. 21, No. 50 by score alone: the placement terms moved other stories past it.
- AI judgeJudge 2claude-haiku-5-5
- Deep, well-evidenced MySQL/InnoDB buffer pool performance investigation with benchmarks and a fix; highly technical but niche to database engineers, so moderate breadth and significance.
- AI judgeJudge 3gpt-5.6-luna
- A detailed, evidence-rich engineering investigation of a major InnoDB regression and a tested mutex/LRU fix, with reproducible benchmarks and implementation specifics. It is highly useful to database and systems practitioners, though narrower than general tech coverage.
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.62total under rubric v2.3Contestedjudges differ by 0.41 on overclaim
- Significance0.60
- Reader interest0.70
- Audience breadth0.44
- Practical relevance0.63
- Substantiated0.90
- Technical depth0.95
- New information0.93
- Counts against: Promotional0.05
- Counts against: Overclaim0.34
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.64 | 0.45 | 0.72 | 0.60 | 0.27 | +0.24 | +0.145 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.65 | 0.60 | 0.84 | 0.70 | 0.24 | +0.26 | +0.181 |
| Audience breadthHow many people who build technology does it concern? | 0.49 | 0.35 | 0.48 | 0.44 | 0.14 | +0.13 | +0.057 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.60 | 0.55 | 0.75 | 0.63 | 0.20 | +0.22 | +0.140 |
| 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.97 | 0.80 | 0.92 | 0.90 | 0.17 | +0.05 | +0.045 |
| Technical depthHow technically substantive is it? | 1.00 | 0.90 | 0.96 | 0.95 | 0.10 | +0.05 | +0.048 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.87 | 0.95 | 0.98 | 0.93 | 0.11 | +0.05 | +0.047 |
| 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.06 | 0.05 | 0.03 | 0.05 | 0.03 | −0.19 | −0.009 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.59 | 0.25 | 0.18 | 0.34 | 0.41 , above the contested threshold | −0.11 | −0.037 |
| Sum of contributions | +0.615 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.615 | ||||||
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-10-31/21/"><img src="https://rubric.hrih.si/badge/2026-10-31/21.svg" alt="Ranked #21 on Rubric, 31 Oct 2026" width="245" height="28"></a>Claim check
Claim check: 1 matches source · 1 no source given · 6 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 checkBenchmark result
On one of Mark Callaghan's tests, MariaDB 11.8 went from 20,326 to 57,052 QPS (about 2.8 times) with a review revision of the fix.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “On one of Mark Callaghan’s tests, 11.8 went from 20,326 to 57,052 QPS (about 2.8 times) with a review revision of the fix”
The source says No passage could be compared.
Source cited by the article: github.com/MariaDB/server/pull/5763
Couldn’t checkBenchmark result
Jonathan Miller independently validated the merged fix on a second host, with even larger gains on 11.8, 12.3 and 13.1.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “Jonathan “Jeb” Miller validated the merged fix independently on a second host, with even larger gains on 11.8, 12.3 and 13.1”
The source says No passage could be compared.
Source cited by the article: mariadb.org/mariadb-foundation-reproducing-and-validating-mdev-37992-with-taf
Couldn’t checkVersion
In MariaDB 10.5, Marko Mäkelä removed the multiple InnoDB buffer pool instances.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “In MariaDB 10.5, Marko Mäkelä removed the multiple InnoDB buffer pool instances (MDEV-15058”
The source says No passage could be compared.
Source cited by the article: jira.mariadb.org/browse/MDEV-15058
Matches sourceBenchmark result
In Mark Callaghan's MDEV-37992 test, throughput was 73,106 QPS on 10.4.34 and about 35–40% of that from 10.5 on (e.g. 29,832 on 10.5.29), with 10.8.8 as an exception at 76,104.
The cited source says the same thing.
The article says “About 35–40% of the 10.4 throughput from 10.5 on, with one strange exception: 10.8.8”
The source says “73106 10.4.34 29832 10.5.29”
Source cited by the article: jira.mariadb.org/browse/MDEV-37992
Couldn’t checkCausal conclusion
Changes to freed-page handling in 10.5 (MDEV-15528 and MDEV-8139) caused the page cleaner to remove freed pages from the LRU list and tick freed_page_clock, which enabled LRU promotion in in-memory workloads and caused the regression.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “as a side effect, when purge frees an undo page, or a B-tree page is freed, the page cleaner now removes it from the LRU list, and so ticks the…”
The source says No passage could be compared.
Source cited by the article: jira.mariadb.org/browse/MDEV-15528
No source givenCausal conclusion
10.8.8 was fast because a full buffer pool leaked by MDEV-30671 left hot pages already in the young sublist, so it was fast by accident.
The article gives no link or citation for it.
The article says “So I think 10.8.8 was fast by accident”
The source says No source to compare with.
Couldn’t checkBenchmark result
On main, a build where buf_page_peek_if_too_old() always returns false reached 57,286 QPS versus 18,945 for the unmodified base.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “gate 57,286 0.99 0”
The source says No passage could be compared.
Source cited by the article: jira.mariadb.org/browse/MDEV-37992
Couldn’t checkBenchmark result
With the fix, 11.8 is about 9% faster than 10.4.34 on this test, and on the second host 11.8 with the fix reached 66,653 TPS versus 62,400 TPS for 10.4.34.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “On the same host, 10.4.34 got 62,400 TPS”
The source says No passage could be compared.
Source cited by the article: mariadb.org/mariadb-foundation-reproducing-and-validating-mdev-37992-with-taf
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 1 pts, not on front page
Recorded for context only, checked 31 Oct 2026, 05:46 UTC. It played no part in the ranking.