Comments on: Multiple Execution Paths

By: Gail

Gail — Thu, 16 Feb 2012 14:52:43 +0000

Yes, but….

By doing that you get a plan for the average case, not necessarily the best case.
http://sqlinthewild.co.za/index.php/2008/02/25/parameter-sniffing-pt-2/

By: suresh

suresh — Thu, 16 Feb 2012 14:34:10 +0000

Hi Gail
Since it’s an onld post, I am not sure if it will be replied. But I do remember using and reading somewhere that to avoid parameter sniffinf, we can receive the passed parameters in variables declared inside the proc and then use those variables instead of hardcoaded values. Isn’t that true? Use of seprate proc for each IF statement somewhat looks intimidating to me if my proc has many if statements.

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)