Understanding Graphical Execution Plans - Part 3: Analyzing the Plan

  • darrenwhite

    SSChasing Mays

    Points: 634

    Comments posted to this topic are about the item Understanding Graphical Execution Plans - Part 3: Analyzing the Plan

  • OldCursor

    SSC Eights!

    Points: 936

    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!

    🙂

  • darrenwhite

    SSChasing Mays

    Points: 634

    "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.

  • Grant Fritchey

    SSC Guru

    Points: 395586

    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

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • Grant Fritchey

    SSC Guru

    Points: 395586

    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

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • darrenwhite

    SSChasing Mays

    Points: 634

    "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

  • OldCursor

    SSC Eights!

    Points: 936

    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

  • Grant Fritchey

    SSC Guru

    Points: 395586

    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

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • Marcia J

    SSCertifiable

    Points: 5636

    Grant Fritchey (2/25/2014)


    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.

    Bless you!

  • OldCursor

    SSC Eights!

    Points: 936

    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

  • Grant Fritchey

    SSC Guru

    Points: 395586

    OldCursor (2/25/2014)


    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

    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

    The Scary DBA
    Author of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd Edition
    Product Evangelist for Red Gate Software

  • OldCursor

    SSC Eights!

    Points: 936

    They couldn't afford you Grant - that's why I'm there!

  • AZJim

    Default port

    Points: 1432

    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.

  • darrenwhite

    SSChasing Mays

    Points: 634

    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

  • AZJim

    Default port

    Points: 1432

    Ok. Nevertheless, the article was very helpful. Thanks.

Viewing 15 posts - 1 through 15 (of 20 total)

You must be logged in to reply to this topic. Login to reply