Given the following statements, where in the SELECT statement's plan do you see that it doesn't need the customer_2 table?
Also interesting is the difference between the SELECT plan and the UPDATE plan when partitioned views are built based on the MSDN docs. https://technet.microsoft.com/en-US/library/ms190019(v=SQL.105).aspx. The SELECT doesn't show the 'other' table, similar to the above but the UPDATE does.
I was hoping the first version would work with an update. Other than the facts don't support it in MSDN, it really seems like it should work based on the fact that the constant in the view mimics the check constraint.
You don't, because the contradiction 1 = 2 was detected during optimization, and that part of the tree was thrown away. This is also part of the reason the query wasn't subject to simple parameterization. If you set the database option FORCED PARAMETERIZATION ON, you will see the more general form of the plan, with start-up filters below the union all.
I was hoping the first version would work with an update.
There is still some simplification performed (hence the Constant Scan). Contradiction detection does not go as far as removing the sequence though. This is simply because a rule to perform that empty set removal hasn't been implemented.
Again, with forced parameterization set, you see a more general plan without simplifications based on particular values, featuring start-up filters again.
Plans can often be simplified by the action of generic contradiction detection; specific rules may then be able to remove guaranteed-empty subtrees, though not all possibilities are covered. Partitioned views never received much love in this area. Update plans in general often don't simplify as much because of the risks involved (update processing is ridiculously complex already).
Is there any thing that can be done to improve the performance of the function with the uploaded plan?