Yes. Every day. The developers here write SQL that runs acceptably for a given schema at a given point in time. Unfortunately, the code pattern isn't scalable (

Yes. Every day. The developers here write SQL that runs acceptably for a given schema at a given point in time. Unfortunately, the code pattern isn't scalable (which is generally why people say that RDBMS' can't "scale" anyway, but that's a different rant) and performance changes, sometimes dramatically. Where a LEFT OUT JOIN ... WHERE outer.value is NULL worked great for an anti-semijoin earlier, NOT EXISTS may be better. What jpitz is talking about are statistics that are tracked by the engine. They are a key part of how SQL Server's CBO determines the best plan to access the data. As data grows, chances are you're going to get skew on the keys that you've defined. If your data is such that the counts and distinct counts of your keys are guaranteed to remain consistent, then you have a lower chance of plan changes as data scales.