Question

If i have a view that generates multiple columns:

CREATE VIEW dbo.foo AS
SELECT 
    id,
    SUM(SELECT [...] ) AS c1,
    STDEV(SELECT [...] ) AS c2,
    AVG(SELECT [...] ) AS c3,
    MIN(SELECT [...] ) AS c4,
    MAX(SELECT [...] ) AS c5,
    SUM(SELECT [...] ) AS c6,
    [...]
    COUNT(SELECT [...] ) AS cN,
FROM Table
GROUP BY id

But i end up only asking for one of those calculated values:

SELECT id, c382
FROM foo
WHERE id = 42

Will SQL Server calculate all column values, only to ignore them?

In my experience, the answer seems to be “yes”. A query:

SELECT id, c382
FROM foo
WHERE id = 42

will be slower than i think it should be. If i break the abstraction, duplicating the code i want:

SELECT id, c382
FROM (
      SELECT 
       id,
       MAX(SELECT [...] ) AS c382
   FROM Table
   GROUP BY id
) AS MiniView
WHERE id = 42

The query runs better.

Or perhaps it’s in more real world constructs that it begins to fall apart:

SELECT bar.*, foo.384
FROM bar
    INNER JOIN foo
    ON bar.Bing = foo.id
WHERE bar.Reticulated = 'splines'

Am i crazy, or is SQL Server (2000) crazy?

Answer 1

This is how it typically works in SQL Server 2000. This is also largely fixed in SQL Server 2005 and later.