![\"LiveQueryStats\"](\"https:\/\/www.sqlinthewild.co.za\/wp-content\/uploads\/2016\/03\/LiveQueryStats.png\" "\\"LiveQueryStats\\"")
<\/a><\/p>\nEnable that and run a query, and you get an execution plan immediately, one with a few more details in it than we\u2019re used to.<\/p>\n
I\u2019m not sure what the times on the operators show, because a constant scan wouldn\u2019t take over 4 seconds, it generates a single number. I suspect it\u2019s the time between the first row request and the operator returning \u2018no more rows\u2019, but I\u2019d have to test more to be sure.<\/p>\n The percentage done is probably based on the estimated row count, because on this plan all the operators went to 99% done instantly. The two numbers underneath the % done are the number of rows currently processed and below that the estimated number of rows.<\/p>\n It\u2019s clear there\u2019s a severe row estimation problem here. The last nested loop join estimated 97 rows and, at the point the screenshot was taken, had processed 170500 rows. It\u2019s a pity that the estimated executions isn\u2019t shown as well, as it makes identifying row estimation errors slightly harder for operators that execute multiple times (eg the key lookup). https:\/\/www.sqlinthewild.co.za\/index.php\/2009\/09\/22\/estimated-rows-actual-rows-and-execution-count\/<\/a><\/p>\n Identifying this kind of problem is, I think, one of the primary uses for Live Query Stats (other that using it to see how the QP works). The old example of \u2018it ran fast yesterday and slow today, why?\u2019 can be at least partially answered with Live Query Stats. Run the query with it turned on and see what plan is used and what row counts are flowing through them. Combine that with Query Store\u2019s history of what plans were used yesterday, and we have a very powerful way of identifying why something is running unusually slow.<\/p>\n However is it something that should be used sparsely in production, as it does add some\u00a0 overhead.<\/p>\n<\/a><\/p>\n