February 24, 2014 at 9:37 pm
Comments posted to this topic are about the item Understanding Graphical Execution Plans - Part 3: Analyzing the Plan
February 25, 2014 at 3:21 am
This is the first time I have ever seen practical and really meaningful advise about the "black art" of query optimization. The timing is perfect because I need to do a lot of it at the moment.
Thanks for a very informative and helpful series of articles!
🙂
February 25, 2014 at 6:23 am
"This is the first time I have ever seen practical and really meaningful advise about the "black art" of query optimization. The timing is perfect because I need to do a lot of it at the moment.
Thanks for a very informative and helpful series of articles!"
I appreciate your feedback I am glad you found it helpful. If you would like more depth on the subject, I would recommend Grant Fritchey's book.
February 25, 2014 at 6:39 am
Nice article.
A couple of notes. You state that the plan is read from right to left. That's not completely true. The logical processing order of the plan is from left to right, like reading a book. The data flow is from right to left. Frequently you're going to follow the data flow, but there are some plans, especially ones involving temporary storage in spools, that can only be appropriately understood by reading them left to right. That was a mistake in my first book that I fixed in the second edition.
You state that operator costs are estimates, good. But then you go on to implicate that they have direct correlation to performance and that's just not true. They're internal measuring sticks of meaning only to the optimizer and don't relate to the real world in any significant way. I'd be as clear as possible there. That's another thing I didn't make sufficiently clear in the first edition of my book.
Decent summary of how to read execution plans. Well done.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 25, 2014 at 6:41 am
OldCursor (2/25/2014)
This is the first time I have ever seen practical and really meaningful advise about the "black art" of query optimization. The timing is perfect because I need to do a lot of it at the moment.Thanks for a very informative and helpful series of articles!
🙂
For more, follow the links in my signature below. The Execution Plans book is free as a download from here[/url] if you don't want a paper copy.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 25, 2014 at 6:55 am
"Nice article.
A couple of notes. You state that the plan is read from right to left. That's not completely true. The logical processing order of the plan is from left to right, like reading a book. The data flow is from right to left. Frequently you're going to follow the data flow, but there are some plans, especially ones involving temporary storage in spools, that can only be appropriately understood by reading them left to right. That was a mistake in my first book that I fixed in the second edition.
You state that operator costs are estimates, good. But then you go on to implicate that they have direct correlation to performance and that's just not true. They're internal measuring sticks of meaning only to the optimizer and don't relate to the real world in any significant way. I'd be as clear as possible there. That's another thing I didn't make sufficiently clear in the first edition of my book.
Decent summary of how to read execution plans. Well done. "
Thanks again, Grant, for the encouragement and clarifications.
Darren
February 25, 2014 at 7:05 am
Grant
Thanks, I've already read some of your articles and I got your book just a couple of days ago. I haven't had much time to read it yet - the subject is a bit 'dry' you must admit - but I will very soon!
Thanks
February 25, 2014 at 7:12 am
Ow!
Dry? Now way! I love it. Can't get enough. If you want a quick hit on what to look for in plans, I've got a short list here.[/url]
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 25, 2014 at 1:58 pm
February 25, 2014 at 2:14 pm
Thanks Grant
Now . . . if you enjoy it so much perhaps you could pop round and sort out my clients problems - it would save all that studying.
But unlike most other problems faced by a sql server developer (like how do I find the date of the third Tuesday in the month three months ago etc etc) resolving performance issues can't be achieved simply by a quick search on <insert-the-name-of-your-favourite-search-engine-here> so I guess in that respect it presents a more satisfying challenge (I think).
Your helpful books, articles and tips go a long way to make my efforts a little more successful and therefore more satisfying.
Thanks again
February 25, 2014 at 3:09 pm
OldCursor (2/25/2014)
Thanks GrantNow . . . if you enjoy it so much perhaps you could pop round and sort out my clients problems - it would save all that studying.
But unlike most other problems faced by a sql server developer (like how do I find the date of the third Tuesday in the month three months ago etc etc) resolving performance issues can't be achieved simply by a quick search on <insert-the-name-of-your-favourite-search-engine-here> so I guess in that respect it presents a more satisfying challenge (I think).
Your helpful books, articles and tips go a long way to make my efforts a little more successful and therefore more satisfying.
Thanks again
Love to. Should I send my rate over?
You're right though. It's a much more difficult problem, especially when you get past all the standard issues.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 25, 2014 at 3:53 pm
They couldn't afford you Grant - that's why I'm there!
February 26, 2014 at 1:32 pm
Darren ... I am a bit confused. You mentioned regarding the detailed breakdown box that, "The Operator Cost is the addition of the CPU and I/O Costs." When I add these two together, I get a value of 0.2789314, which is considerably higher than the Operating cost listed of 0.0173234. I have reread what you wrote, but still don't get it. Can you clarify? Thanks.
February 26, 2014 at 2:46 pm
jim.drewe (2/26/2014)
Darren ... I am a bit confused. You mentioned regarding the detailed breakdown box that, "The Operator Cost is the addition of the CPU and I/O Costs." When I add these two together, I get a value of 0.2789314, which is considerably higher than the Operating cost listed of 0.0173234. I have reread what you wrote, but still don't get it. Can you clarify? Thanks.
I didn’t realize that numbers did not add up in my example. It was NOT a good example. Normally the IO cost and CPU cost add up to the Operator Cost. I am at a loss as to why this is not the case in my example. If you try it on your own, I think you will see that the two costs normally add up to the operator cost. Sorry for the confusion.
Darren
February 26, 2014 at 2:48 pm
Ok. Nevertheless, the article was very helpful. Thanks.
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply