Question

I’ve got a stored procedure which used to take around 25s to execute.

I’ve used the Execution plan feature of SSMS to track down the performance bottleneck, and have identified that I had a very expansive query where I was auto-joining several times on a single view. I cached it into a CTE, launched again my stored procedure, checked that the relative weight of that specific query in my batch had dropped from 30% to 2%, and started looking for further optimization opportunities.

Actually, the view that I had just cached was used all over the place, so I decided to store the values I needed into a @local table, and to use this table everywhere in my stored procedure. 93% of my batch is now devoted to this line :

insert into @vwActivityCache
select * from vwActivity where n in (@n,@n-1,@n-2) 

And this line takes around 2s to execute. (@vwActivityCache contains around 10k rows)

So far, so good.

The thing is that my stored procedure still takes 25s to execute. (after the first exec which takes longer)

I’ve tried commenting all the queries after the above insert, and the execution takes 2s, as expected.

I’ve speculated that it could be caused by the time needed to transfer the data back to my sql client (despite the client statistics didn’t imply this at all), so I tried removing the final select of the procedure (which now returns nothing), but I’m still stuck at 25s. I’ve also tried executing directly from the sql server box, 25s as well.

If I remove everything but the local table declaration and the insert that populates it, the stored procedure takes 2s to execute, as expected.

For each query making use of my @vwActivityCache table that I uncomment, the execution time increases by a few seconds (even-though the execution plan claims the uncommented query took 0% of the batch time to execute), till I reach my initial 25s when everything is uncommented.

Unfortunately I can’t post the stored procedure nor the execution plan here, but I was wondering if someone had any idea of the reasons that could cause a 2s query to take 93% of the execution time of a 25s procedure !

Update : switching @vwActivityCache to a temp table (#vwActivityCache ) reduced the execution time from 25s to 6s.

Answer 1

The costs shown in even the actual Execution plan are based on estimates and need to be taken with a big pinch of salt.

As soon as you introduce a table variable the estimates will probably be wrong as statistics are not maintained for table variables and they are based on the assumption that the table variable only has one row.

You could try a #temporary table as at least that will have statistics created for it meaning the costs shown in the plan may be a bit more accurate (and it might then choose a different plan based on this anyway) .