If you are joining 12 tables for operational data, you have a design flaw. That’s a reporting query pattern.
Often temp tables, CTEs etc are needed as an immediate fix with redesign as a long term fix. The query planner simply can’t optimize that in a reasonable time or it’s beyond there scope if what it can optimize. Also their solution to “joining in memory” is common.
My DB query rule of thumb:
If the query is hard for you to understand, it’s hard for the planner to understand.
Default to small fast simple queries and pipeline them together.
Pleasant to hear about the Object-Relational Impedance Mismatch [1], haven't heard about that concept for a long time - maybe a decade!. The reason I like Dapper [2] is that it makes you use your own sql.
> PostGIS is a great database and its foundational data type is geography.
Hate to "well ackchyually" the author here, but I'm gonna. The foundational data type in PostGIS is not geography, but geometry. geography is geodetic layer on top of geometry. I honestly don't use geography that much because it only supports a subset of the geometry functions.
I personally hate YAGNI, because it so often leads to balkanized APIs that only implement the "needed" features and omit things that a reasonable person would expect because they weren't needed initially. Far better to have a clear and explicable model that is fully and consistently implemented.
DDIA is great. I read and re-read the small section about LSM merge tree in the first and second edition of the book and got interested in this stuff. It is always a pleasure to read about internals.
the impact of recursivedoubts i.e htmx creator on software engineering practices and adhering to simplicity is monumental but the industry keeps heading towards complexity.
Carl's Required Reading
(carlkolon.com)228 points by cckolon 1 August 2026 | 30 comments
Comments
He links here as some kind of damning proof that ORMs are default bad.
https://openai.com/index/scaling-postgresql/
“It’s a poor craftsmen who blames their tools.”
My ORM rule of thumb: ORM for CRUD not Reports
If you are joining 12 tables for operational data, you have a design flaw. That’s a reporting query pattern.
Often temp tables, CTEs etc are needed as an immediate fix with redesign as a long term fix. The query planner simply can’t optimize that in a reasonable time or it’s beyond there scope if what it can optimize. Also their solution to “joining in memory” is common.
My DB query rule of thumb: If the query is hard for you to understand, it’s hard for the planner to understand.
Default to small fast simple queries and pipeline them together.
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... https://www.parsonsmatt.org/2017/10/11/type_safety_back_and_... https://lwn.net/Articles/336262/ https://tomasp.net/blog/2015/library-frameworks/ https://ratfactor.com/cards/not-quite-the-same https://matklad.github.io/2023/11/15/push-ifs-up-and-fors-do...
grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
seem very confusing to grug
^ This is the best and funniest paragraph of text that I’ve read this year
Edit "lets" -> "makes".
[1] https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe...
[2] https://github.com/DapperLib/Dapper
Hate to "well ackchyually" the author here, but I'm gonna. The foundational data type in PostGIS is not geography, but geometry. geography is geodetic layer on top of geometry. I honestly don't use geography that much because it only supports a subset of the geometry functions.