Their publication
SQLPress
SQL · sqlpress.com
Databases, queries and the people who run them: PostgreSQL, MySQL, SQL Server, Oracle and data engineering.
Author
Elias Rowe
Writes SQLPress — databases, queries and the people who run them.
Elias Rowe writes about database engineering, SQL performance, and production systems. He focuses on measurable behavior, practical trade-offs, and conclusions that can be reproduced rather than assumed.
SQLPress covers how database systems behave: query planning and execution, storage and internals, concurrency, and the operational side of running these systems in production. Documentation describes what a system does, and most articles describe what to do about it; the layer in between — why it behaves that way, measured on a stated setup, with the boundary of the result written down — is what the site is for. Its readers already write SQL, and will notice when a claim is hand-waved.
The method is narrow on purpose. A claim is worth publishing when it can be checked: the version exact, the setup written down, the reasoning visible from the observed behavior to the conclusion. That standard runs both ways — articles carry hypotheses that turned out wrong, results that failed to reproduce, and questions left open because the evidence ran out. Corrections are published in place, with the date and the evidence that changed the conclusion.
Elias Rowe is a publishing byline. It identifies the author of every article at sqlpress.com, and nothing else — it is not the operator of the domain named in that site's legal pages.
Every issue so far
Relational modeling describes the entities and lets queries follow. Document modeling inverts that, and the inversion is the whole trade.
Past the point where the server can execute work in parallel, adding connections adds queueing rather than throughput — and moves the queue somewhere worse.
Column order decides which queries a composite index can serve. The rule follows from the structure, and so do the cases where it does not hold.
InnoDB stores the table inside its primary key. Almost every MySQL indexing consequence, good and bad, follows from that single decision.
Transaction pooling is what makes PgBouncer worth deploying, and it silently removes session state your application may depend on.
Which variant you ran decides whether the numbers in front of you are the planner's estimate or a measurement, and whether the pages came from cache.
One query for the list, then one more for every item in it. The cost is per statement, which is why the profiler shows a fast database and a slow request.
An index the planner ignores is usually a row-estimate problem. The fix starts with what the optimizer expected, not with the index definition.
Elsewhere in the network
ElephantPHP · JS Ledger · JVM Scope · PyDepth · CSharpMind · Gopheria — six more languages, six more specialists, one imprint. Every language has a page of its own.