arbarnhart - you hit the nail on the head. When you say, "...but I often choose which way to do something based on how long it will take to code because I have no clue what the performance impact of different alternatives is." You exemplify the nature of the problem. If you have a complex query, there is a very good chance you could write it three to four different ways - and produce the exact same results. ONE of those four ways will be most efficient. I have personally re-written stored proc's that have performed anywhere from 2 to 100 times faster simply by looking at a few execution plans, understanding how the engine goes out to get the data and re-writing the code to be more efficient, make better use of stats and indexes, and before I propose any index restructuring.

Don't get me wrong - I applaud your honesty as much as RBAR and I certainly don't knock you for trying. After all, what choice did you really have? 🙂 I just couldn't resist quoting you on this because I think that this approach to TSQL coding is very common and it furthers my point: SQL Server certainly won't raise an error if you construct code that is technically "legal" but terribly inefficient. It will dutifully try to execute it the best it can, churning away for minutes or hours if necessary until it completes or becomes victim of deadlock or connection timeout or gets killed by somebody like me! 😉