I recently wrote about the Actual I/O Statistics property that you can find in an execution plan plus run-time statistics, which allows you to see exactly how much I/O was done by each individual operator. This is a great feature and I’m very happy with it. But, as I already indicated at the end of that post, there are some issues as well. Let’s take a look at the dark side of this property. Error, does not compute So, let’s look at an example, based on this simple query: Transact-SQL SET STATISTICS IO ON; SELECT sod.OrderQty, sod.UnitPrice FROM Sales.SalesOrderDetail AS…

The June 2020 edition of T-SQL Tuesday is hosted by Kenneth Fisher (b|t). He wants us to share some tips and tricks … for anything that’s not SQL Server. I first thought I’d have to sit this one out. I’ve never been really big on tips and tricks. I sometimes look in awe at all the handy stuff I see other people do. And then I try to memorize it all … and fail miserably. For me, it is apparently more efficient to just use the simple, standard methods, then it is to try to memory all the hacks and…

One of the things that many people look at when tuning their queries is the amount of I/O required per execution. Of course, when the CEO is waiting for their favorite report to render, we only care about elapsed time. But for most other queries, especially for those that run thousands of times each day, reducing I/O is often our main objective. The old ways The standard method to get insight in the amount of I/O that was done while executing a query is to precede the query with the statement SET STATISTICS IO ON . (The same setting can be…

Over the past weeks, I have published several posts about Actual Number of Rows, Estimated Number of Rows, how they are reflected in the arrow width in the graphical execution plan, and several scenarios where this can be wrong or misleading. And now, after telling you in my previous post that this was the last in this series, I am back with yet another one. I discovered this only very recently. It was not planned for the series, because I was not aware of it. Until I ran into it while preparing a demo, got fooled by it, investigated it,…

This is the fifth and final post in my May 2020 series about the Actual and Estimated Number of Rows properties in execution plans. In the previous posts, I talked about how you can use them, the confusion a Nested Loops operator can cause, how sometimes the graphical representation is based on input rather than output, and how missing nodes can catch one off guard. This last part focuses on the issue that is perhaps the most common of all: the lack of data reported by a Compute Scalar operator, and how this affects the graphical execution plan Compute Scalar…

I have this month already blogged about good ways to use the Actual Number of Rows and Estimated Number of Rows properties, about the confusing representation on operators that execute more than once, and about the confusing choice to render arrow width based on the Number of Rows Read when it is available. Today I’ll show yet another case where execution plans can mislead you. Not as common as the previous two situations, but with the potential to cause heavy panic when you first encounter it. Misleading estimates caused by missing nodes The issue I will talk about today is…

In my last two posts, I presented use cases for the Actual Number of Rows and Estimated Number of Rows properties, and showcased one shortcoming. Was that the only problem with these properties? Unfortunately not. Rows read versus rows returned The visual of the arrows in an execution plan strongly suggests that they represent the flow of rows from one operator to another. And hence, the width of that arrow strongly appears to be an indication of how many rows are passed between the connected operators. That used to be always the case. But unfortunately, this changed in December 2017…

In my previous post, I talked about the Actual Number of Rows and Estimated Number of Rows properties, their visual representation in execution plans, and the most important ways in which this can be used. But life is not always perfect, and Microsoft likes to remind us of that. Sometimes, these properties report values in weird and confusing ways. Sometimes the arrow width, as the visual representation in the execution plan, misleads us. Let’s look at one such case. Average per execution versus total of all executions When looking at the Actual and Estimated Number of Rows properties of an…

The May 2020 edition of T-SQL Tuesday is hosted by Glenn Berry (b|t). On the surface, his topic is about “Folding@Home”. But if you read closer, you’ll see that Glenn actually asks: “what are you doing as a response to COVID-19?” And while Glenn does suggest that zooming in on how we optimize our hardware for Folding@Home might be a good idea for this round of T-SQL Tuesday, the topic allows for more freedom. I’ll grab that freedom and use it to talk about something else I do as a response to COVID-19. Execution plans? Yes, execution plans It should…

This month (May 2020), I will post several blog posts, all about the same theme: row counts in execution plans, their representation as arrow width; how to use it, and how it can confuse you. Of all the properties you find in execution plans, the Actual Number of Rows and Estimated Number of Rows properties are perhaps the most useful and most used, and definitely in the top three. They can be used for many things, and are extremely valuable. But there are some gotcha’s that a lot of people are unaware of. In this first post, I will highlight…