Does SQL Server propagate WHERE conditions in complex views?

Question

I\'ve followed this question with a full example in case it isn\'t clear what I mean from the question.

I\'ve made a view which joins data from about five tables. The t

Answer 1

Generally, the optimizer will handle this with aplomb, but as the query and implied subqueries become increasingly complex, the chances that the optimizer will choose the proper execution path diminishes accordingly. This can be aggravated by having more indexes on the tables, or very similar indexes on the tables it will be examining.

As a general rule, I try to discourage joining to views, and I strongly discourage creating views that are comprised of other views.

Answer 2

This is called predicate pushing.

SQL Server is generally good at this though there are some constructs where there have been problems (e.g. see the final part of this article).

Check the execution plan to see where the predicate is applied.

Answer 3

The engine will do whatever it thinks is fastest. If you have that field indexed, and your JOIN keys are all indexed, it may or may not run that filter first.

It may actually run the filter LAST if the WHERE clause is more expensive (i.e. unindexed) - that way the expensive operation is running on the smallest result set.

Ther only way to know for sure is to run the query and check the execution plan (ACTUAL not estimated).