Comments on: When Less Reading is a Good Thing

By: Log Buffer #151: a Carnival of the Vanities for DBAs | Pythian Group Blog

Log Buffer #151: a Carnival of the Vanities for DBAs | Pythian Group Blog — Fri, 26 Jun 2009 16:53:51 +0000

[...] cool. I learned this from the Fonz. But look at this, Jeremiah Peschka says there are circumstances when less reading is a good thing. I’m confused! What else does he say? “Less reading is a good thing when you’re [...]

By: Jeremiah Peschka

Jeremiah Peschka — Fri, 19 Jun 2009 19:33:38 +0000

I keep making that argument, but nobody listens to me

Also, it is entirely possible, given the way this application is built, for a specific user to have access to 50 states and have that change to 45 states pretty quickly due to changes in security restrictions and also the constant ETL process from the mainframe.

The other issue is that we’d need to cache the state list for each user, because of the security in the app, so it might create some problems with memory use on the web server.

By: Michelle Ufford

Michelle Ufford — Fri, 19 Jun 2009 19:27:48 +0000

Regarding this statement…

“Considering that this stored procedure gets called thousands and thousands of times a day, that’s a HUGE savings.”

States don’t change very frequently. Any thought to caching the state list in the application layer and save those 2 reads per 1k+ calls?

By: Andy Irving

Andy Irving — Fri, 19 Jun 2009 08:34:11 +0000

Just to confirm what you said, from http://technet.microsoft.com/en-us/library/ms181151.aspx
In SQL Server Enterprise Edition, the query optimizer automatically considers the indexed view. To use an indexed view in all other editions, the NOEXPAND table hint must be used.

Dennis, i think what you’re seeing is THAT EE will act like it does with filtered indexes in 2008, and consider the indexes for use in the plans (which only happens if you don’t specify noexpand).

By: Jeremiah Peschka

Jeremiah Peschka — Thu, 18 Jun 2009 20:55:03 +0000

Denis, you have a great point! My view, technically, is bunk without the schema. I’ll change that.

When I ran this on my production instance, I saw the opposite of what you saw and ended up with my code never using the indexed view unless I specified WITH(NOEXPAND). I suspect, though, this may be due to the prevalence of that execution plan in the plan cache.

By: SQLDenis

SQLDenis — Thu, 18 Jun 2009 20:29:33 +0000

Hey, you forgot to mention the gazillion SET options that have to be supplied to create the view
Also you need dbo.Locations in the view definition or you can’t create it

just curious, when you run this

SELECT l.ClientID,
l.[STATE]
FROM Locations AS l
GROUP BY l.ClientId, l.[STATE]

|–Clustered Index Scan(OBJECT:([tempdb].[dbo].[LocationStates].[CIX_Locations_ClientID_State]))

it uses the view index for me

also running this without a hint

SELECT STATE
FROM dbo.LocationStates AS x
WHERE ClientId = 1;

gets me this plan

|–Stream Aggregate(GROUP BY:([LocationStates].[STATE]))
|–Clustered Index Seek(OBJECT:([tempdb].[dbo].[LocationStates].[CIX_Locations_ClientID_State]),
SEEK:([LocationStates].[ClientID]=Convert([@1])) ORDERED FORWARD)

By: Kevin Kline

Kevin Kline — Thu, 18 Jun 2009 20:26:55 +0000

Good tip, Jeremiah!

By: Aaron Bertrand

Aaron Bertrand — Thu, 18 Jun 2009 20:10:07 +0000

As an FYI, I have observed at least one case where I had better performance when using NOEXPAND on Enterprise Edition. I’ll try to dig up the details but IIRC the index on the view was not being chosen.