Execution Strategies and Runtime Behavior

Joins, parallel execution, memory grants, spills, and adaptive execution.

93 associated posts89 primary posts

Production DBA

Office Hours: One-Word Answers Edition

Some of the questions y'all post at https://pollgab.com/room/brento are pretty straightforward. Let's get 'er done. LetTheDbaHandleIt: My friend needs to track who has accessed what data. This is easy at OS and app level, but how can my friend verify that those who have direct DB access are not snooping on data inappropriately? e.g. payroll or…

Read more about Office Hours: One-Word Answers Edition 5 comments — Join the discussion
T-SQL & Development

Don’t Treat SQL Like a Programming or Scripting Language.

In a programming language like C# or Java, you tell the computer what to do, in order. Get the customers from California, then get their invoices, then sum the total. SQL, on the other hand, is a declarative language where you declare the shape of your result set: Get the total sales from Californian customers.…

Read more about Don’t Treat SQL Like a Programming or Scripting Language. 6 comments — Join the discussion
T-SQL & Development

How Scalar User-Defined Functions Slow Down Queries

When your query has a scalar user-defined function in it, SQL Server may not parallelize it and may hide the work that it's doing in your execution plan.

To show it, I'll run a simple query against the Users table in the Stack Overflow database.
[crayon-6a6ef5ddd02ca499384117/]
I don't have an index on Reputation, so SQL Server has to sort all of the Users by their Reputation. That's a CPU-intensive operation, so SQL Server automatically parallelizes it across multiple CPU cores:

Read more about How Scalar User-Defined Functions Slow Down Queries 13 comments — Join the discussion
Performance Tuning

MAXDOP Isn’t Really MAXDOP. It’s More Like DOP.

Here's how Books Online describes the Max Degree of Parallelism setting: You can use the max degree of parallelism option to limit the number of processors to use in parallel plan execution. And here's what the SQL Server 2019 setup screen says: When an instance of SQL Server runs on a computer that has more…

Read more about MAXDOP Isn’t Really MAXDOP. It’s More Like DOP. 11 comments — Join the discussion
T-SQL & Development

Why Full Text’s CONTAINS Queries Are So Slow

SQL Server's full text search is amazing. Well, it amazes me at least - it has so many cool capabilities: looking for prefixes, words near each other, different verb tenses, and even thesaurus searches. However, that's not how I see most people using it: I've seen so many shops using it for matching specific strings, thinking it's going to be faster than LIKE '%mysearch%'. That works at small scale, but as your data grows, you run into a query plan performance problem.

Read more about Why Full Text’s CONTAINS Queries Are So Slow 33 comments — Join the discussion
Performance Tuning

“UPDATE, INSERT, and DELETE are not normally processed in parallel”

Years ago, when troubleshooting performance, I stumbled across this Microsoft documentation on parallel query processing that says: Certain types of statements cannot be processed in parallel unless they contain clauses, however. For example, UPDATE, INSERT, and DELETE are not normally processed in parallel even if the related query meets the criteria. But if the UPDATE…

Read more about “UPDATE, INSERT, and DELETE are not normally processed in parallel” 12 comments — Join the discussion
Performance Tuning

Where Should You Tune Queries: Production, Staging, or Development?

The #1 fastest way to tune queries is in the production database, on the production server. I know. Put the knife down. You're not happy about that, but hear me out: I'm specifically talking about the fastest way to tune queries. In production, you can guarantee that you're looking at the same data, hosted on the…

Read more about Where Should You Tune Queries: Production, Staging, or Development? 23 comments — Join the discussion