A Fine Slice Of SQL Server
Forrest McDaniel joins tables together:
Even at a full cartesian join, 49 by 49 rows does not produce 27670.
Usually, when the optimizer applies transformations it updates cardinality estimates, but I ran into a particular construction and transformation where it doesn’t (and I don’t know why).
Read on for the example and a workaround that Forrest found.
Comments closedEitan Blumin troubleshoots an odd issue:
A customer reported that running
DBCC CHECKTABLEon several different tables kept failing with the exact same error:Msg 845, Sev 17: Time-out occurred while waiting for buffer latch type 4 for page (1:27527325), database ID 10. Msg 1823, Sev 17: A database snapshot cannot be created because it failed to start. Msg 7928, Sev 17: The database snapshot for online checks could not be created.
Read on to learn more about Eitan’s troubleshooting process, what the cause of the issue was, and the fixes (both the immediate and complete ones) needed to resolve the issue.
Comments closedChris Webb updates a prior post:
Two years ago I wrote a detailed post on how to do performance testing for Direct Lake semantic models. In that post I talked about how important it is to run worst-case scenario tests to see how your model performs when there is no model data present in memory, and how it was possible to clear all the data held in memory by doing a full refresh of the semantic model. Recently, however, a long-awaited performance improvement for Direct Lake has been released which means a full semantic model refresh may no longer page all data out of memory – which is great, but which also makes running performance tests a bit more complicated.
Read on to learn more about the improvement as well as how you can still perform your performance testing.
Comments closedWarda Bibi explains why a large PostgreSQL database restoration can take a long time:
In July 2025, during the PG19-1 CommitFest, I reviewed a patch targeting the lack of parallelism when adding foreign keys in pg_restore. Around the same time, I was helping a client with a large production migration where pg_restore dragged on for more than 24 hours and crashed multiple times.
In this blog, I will talk about the technical limitations in PostgreSQL, the proposed fix, and a practical workaround for surviving large restores.
The reason for the slowdown is a bit wild to me, though I suppose somebody could edit the backup files manually after pg_dump writes them out.
Comments closed