Comments on: Multiple Execution Paths

By: Gail

Gail — Wed, 15 Dec 2010 05:48:39 +0000

As always, it depends.

If a proc is running many times a second you do not want it recompiling on each execution. The overhead will be unpleasant. If the proc is running once a day the recompile overhead is far less of a problem.

By: Dan

Dan — Tue, 14 Dec 2010 22:26:58 +0000

I worry about the recompile option because in a high load (hundred calls per sec) the time and processor spent to recompile could be big ( agree or not ?!).
The option to have more procedures is the right choice IMO.

By: Tsquare

Tsquare — Fri, 05 Mar 2010 23:07:49 +0000

Great Blog!……There’s always something here to make me laugh…Keep doing what ya do

By: Gail

Gail — Mon, 07 Dec 2009 15:23:37 +0000

If you’ve got a proc with multiple if-else branches, based of multiple parameters then you are probably way better off breaking it down into multiple smaller procs. Not sure why you’re concerned with the numbers, the same number queries would exist in the single proc, it’s just a matter of moving them elsewhere.

By: Aalamjeet Singh

Aalamjeet Singh — Mon, 07 Dec 2009 14:26:54 +0000

What happens if the there are more than one parameters which can have multiple combinations of values while calling the master proc? We can’t have n child procs for n number of combinations if n is a large number!

By: Gail

Gail — Sat, 10 Oct 2009 08:48:13 +0000

Bear in mind this was a simplified example. It’s possible to get this problem when all indexes are covering, eg through inappropriate joins or other operators. It’s not just an indexing question.

It’s just a bit harder to generate such an example, which is why I stuck to something simple.

By: Troy

Troy — Fri, 09 Oct 2009 21:38:46 +0000

Thanks for the additional information about the index. I had guessed that there must be one in your example, and defined one that used the TransactionType for the index key, but additionally included the TransactionDate. This has the effect of eliminating the key lookup in the suboptimal plan, so the reads don’t go through the roof as in your example.

So the 2nd recommendation that I hope your readers will keep in mind is to be sure your indexing design is optimal for the types of queries you’re running.

By: Gail

Gail — Thu, 08 Oct 2009 16:05:42 +0000

SQL 2008. 2005 behaves exactly the same way. I did this as a presentation, used SQL 2008 twice and 2005 once.

The point is not avoiding recompiles, the point is that SQL doesn’t recompile and continues using a cached plan even in cases when it’s highly inefficient.

Make sure there is an index on TransactionType. I’m not sure if there’s one on that column in the default adventureworks. Without an index, you’ll get a tablescan no matter what because there’s no other way to evaluate the query
USE [Adventureworks]
GO
CREATE NONCLUSTERED INDEX [IX_TransactionHistory_TransactionType] ON [Production].[TransactionHistory]
([TransactionType] ASC)

By: Troy

Troy — Thu, 08 Oct 2009 15:10:41 +0000

Avoiding recompiles in conditional stored procs via sub-procs is a technique I used in the 6.5 through 2000 days, but I didn’t have a chance to cycle back and see if it still applies for SS2K5 with the new statement-level recompilation feature.

I haven’t yet been able to convince myself that the sub-proc technique is still necessary…

What version and build of SQL Server are you using? I’m unable to duplicate the behavior using SS2K5 Developer Edition 9.00.4035.00 (SP3) on an x86.

I artificially increased the size of the table to 6.8 million rows (copies of itself over and over). Was there any other manipulation you did for the data distribution? Any changes to the indexing as deployed in the AW sample?

Thanks,
TroyK

By: Dave F

Dave F — Mon, 21 Sep 2009 15:27:35 +0000

Having come from a C++ background, I instinctively use sub procedures. Now I know it’s not a bad habit after all. Thanks.