In trying to determine what area of a large query i have is causing performance problems i took three steps. Including the execution plan, setting time statistics to on and printing immediately before and after sections that i believe might cause a problem. Example:
print '1'
SELECT ID FROM Test
print '2'
When i look at my execution plan it says that a certain section is taking up a large percentage of the “cost”. When I compare this percentage to the elapsed time between my print '1' and print '2' it’s seems like there is no way that percentage is even close.
Is it a safe bet to rely on the printed values and the time statistics over the estimated cost? If it is, would it make sense for me to focus on areas that have a large elapsed time between printed values rather than the estimated costs?
If you only print ‘1’ and print ‘2’ then measure the time between when you see the message in your SSMS messages pane then you are falling victim of output buffering between the server and the client. The
print '1'may not immediately sent back to the client, and SqlClient, ADO.Net and SSMS also do some buffering of their own. So overall you may see the ‘1’ in your SSMS results Messages panel way, way later than it actually occured. Much better is to print the time from getdate(), not just ‘1’. This way you take out the buffering from the equation and you can see in the message itself the time when the server executed the ‘print’, not the time when its output was displayed by SSMS.SET STATISTICS TIME ONwill always be more accurate, but is sometimes difficult to understant to which statement exactly it reffers to.What I usualy do is something like this: