I don’t find bugs in SQL Server all that often. I find bugs in my own code all the time.
In this case I double checked, and I think it’s a real SQL Server bug.
When I was recently testing tempdb file usage, I used an Extended Events session that used SQL Server’s histogram target to track sqlserver.file_read events in the tempdb database for a specific session.
I’m sometimes asked if the number of CPU cores used by a query determines the number of tempdb files that the query can use.
Good news: even a single threaded query can use multiple tempdb data files.
You can’t do everything with a columnstore index – but SQL Server’s optimizer can get pretty creative so it can use a columnstore index in ways you might not expect.
One of the coolest things to come to SQL Server Management Studio in a long time might be hard to see at first: it’s tucked away in the Properties Window.
But once you see it, it might just be something that you use all the time.
In many environments, it’s useful to know exactly when an index was created or modified.
Did that last code release help performance, or hurt it? It’s really helpful to know exactly when the code was deployed to prove that your change made something better. Or that you might need to roll it back.
It takes a little preparation to track changes to your indexes, but it’s easy to implement.
Short answer: the SQL Server optimizer will know that the table was truncated, but statistics might not update when you expect.
For the long answer, let’s walk through an example using the WideWorldImporters sample database.
Copyright (c) 2025, Catalyze SQL, LLC; all rights reserved. Opinions expressed on this site are solely those of Kendra Little of Catalyze SQL, LLC. Content policy: Short excerpts of blog posts (3 sentences) may be republished, but longer excerpts and artwork cannot be shared without explicit permission.