Does a SQL Server Computed Column require "persistence" in order for it to be indexed efficiently?

Does a SQL Server Computed Column require "persistence" in order for it to b开发者_开发百科e indexed efficiently?

It's a Name and a LoweredName (computed) column combination. So I don't believe it deals with the precision stuff mentioned in a MSDN article.

---

Contrary to what Mitch has stated, you don't need a column to be persisted for an index to be created (what the MSDN article states is that, if the computed column is not deterministic, then it has to be marked persisted before it can be considered for inclusion in an index.

As to the original question, I'd expect the index efficiency to be as good as for any other column - what metric are we using for the efficiency? I certainly wouldn't expect it to take up more space. There would be some computation overhead during INSERT/UPDATE, but you'd have that whether or not the column was marked as persisted.

There shouldn't be any difference when it comes to querying via the index - the index structure itself would be constructed the same whether this was a real column, a persisted computed column, or an unpersisted computed column.

(Hopefully final edit) - there may be a small performance hit if you're retrieving the computed column, and the computation itself is expensive, when compared with e.g. the network overhead, or other I/O costs. But in the case of converting to lower case, I'd not expect to be able to notice it.

---

No. But there are certain conditions that must be met in order to create an index on a computed column: BOL - Creating Indexes on Computed Columns