Question

Currently I have a procedure that performs 4 operations in the Transaction:

  1. Update record in table A
  2. Update record in table B
  3. Insert record into table C
  4. Delete record from table D

The first operation is performed only when one of the parameters of procedure (@IsUpdateA) is equal to 1.

So from business perspective it looks If @IsUpdateA = 1, the update of table A has to be performed, while step 2, 3 and 4 are always performed.

The question is whether it is better (in terms of efficiency/execution plan) to split such procedure into two, i.e.

  1. First procedure will always perform steps 1,2,3,4
  2. Second procedure will always perform steps 2,3,4

And @IsUpdateA will be checked in application. I can not use procedure in procedure (internal requirement).

Was it helpful?

Solution

The optimizer uses the sniffed parameter values regardless of your procedural logic. Imagine your proc code with only the DML statements and the parameters in it.

So there is a risk that when the plan is generated, the values to be used for the UPDATE are nonsense values when @IsUpdateA = 0. From a performance perspective, that is. Think of the WHERE clause and selectivity. I.e., the plan is created for that UPDATE (which isn't executed) is based on values that give you incorrect selectivity calculation and as a result a bad plan.

Or the other way around, of course.

I.e., having two procs can give you better estimates and in the end better plans.

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top