|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: 2 days ago @ 1:54 AM
Points: 282,
Visits: 501
|
|
Does anybody know why the following
If Exists (Select * From Inserted I Join dbo.T_PaymentItemGroup PIG On PIG.PaymentItemGroupID = I.PaymentItemGroupID Join ...) Or Exists (Select * From Inserted I Join dbo.T_PaymentItem PAY On PAY.PaymentItemID = I.PaymentItemID Join ...) Begin {Do something} Goto TR_End End
might take 10 minutes to run while this version
If Exists (Select * From Inserted I Join dbo.T_PaymentItemGroup PIG On PIG.PaymentItemGroupID = I.PaymentItemGroupID Join ...) Begin {Do something} Goto TR_End End
If Exists (Select * From Inserted I Join dbo.T_PaymentItem PAY On PAY.PaymentItemID = I.PaymentItemID Join ...) Begin {Do something} Goto TR_End End
completes in a few hundred ms? (The code is in a trigger and is being called when about 3500 records are being updated.)
The only thing I can think of is that, in the first version, SQL is spending (a lot of) time deciding which of the two "Exists (Select *" is going to be quicker to execute.
Is this a well known performance problem? Should we be banning "If Exists (Select ...) Or Exists (Select ...)"?
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Tuesday, March 26, 2013 8:41 AM
Points: 2,562,
Visits: 3,451
|
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: 2 days ago @ 1:54 AM
Points: 282,
Visits: 501
|
|
| Really? Do you have any links to further details? That would be very helpful.
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 12:59 PM
Points: 37,640,
Visits: 29,895
|
|
There is not a well known performance glitch with OR. ORs in a where clause used to perform badly on SQL 2000 because the optimiser had few methods to run it (and people often don't index correctly for OR). The limitations with the optimiser are gone in SQL 2005 and above (but people still often don't index correctly for ORs)
Any chance you can post an execution plan for the first one? What is the wait type that the query has during those 10 minutes? The wait type will give us an idea what is causing the delay.
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Tuesday, March 26, 2013 8:41 AM
Points: 2,562,
Visits: 3,451
|
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 12:59 PM
Points: 37,640,
Visits: 29,895
|
|
That's what I was talking about with SQL 2000 and prior optimiser limitations. It's for OR in a where clause (and to be honest, it's far less relevant since SQL 2005), not OR in an IF.
Oh, and as for those examples he gave in that blog post...
The one with the OR:
Table 'SalesOrderDetail'. Scan count 5, logical reads 10564, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times: CPU time = 187 ms, elapsed time = 337 ms.
The one with the Union:
Table 'SalesOrderDetail'. Scan count 10, logical reads 19068, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times: CPU time = 250 ms, elapsed time = 323 ms.
So the 'efficient' version with the UNION uses 60ms more CPU time and does 9000 more logical reads than the 'inefficient' version with the OR. Hmmmm.
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Tuesday, March 26, 2013 8:41 AM
Points: 2,562,
Visits: 3,451
|
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: 2 days ago @ 1:54 AM
Points: 282,
Visits: 501
|
|
Thanks for that. However, I'm not sure I understand its relevance. I haven't got an OR in a WHERE clause. What I'm comparing is
If A Or B {Do something} with
If A {Do something} If B {Do something} aren't I?
Execution plans and wait types would be a bit tricky to get as (inevitably) we only saw the problem on a client's production server.
|
|
|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Wednesday, February 27, 2013 8:41 PM
Points: 448,
Visits: 320
|
|
Just wanted to point out that OR combines two conditions. As far as I know; it means that 'Expression A' and 'Expression B' are evaluated and then the OR operator is applied for evaluating the final result of the 'Expression A OR B'.
So,
IF A OR B BEGIN {do something} END
is not the same as
IF A BEGIN {do something} END IF B BEGIN {do something} END
-Hope is a heuristic search ~Hemanth
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: 2 days ago @ 1:54 AM
Points: 282,
Visits: 501
|
|
Apologies. That should be comparing
If A Or B {Do something} with
If A Begin {Do something} Goto EndIt End If B {Do something}
EndIt:
|
|
|
|