Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Problem with "If Exists (Select ...) Or Exists (Select ...)" Expand / Collapse
Author
Message
Posted Wednesday, January 9, 2013 6:42 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Yesterday @ 3:46 PM
Points: 42,462, Visits: 35,525
In case you missed this...

GilaMonster (1/9/2013)
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

Post #1404745
Posted Wednesday, January 9, 2013 6:47 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 2:23 AM
Points: 367, Visits: 674
It has only been reported on a client's live server, so getting the execution plan would be tricky, the wait type less tricky. But I'm afraid I don't have either to hand immediately. We've been unable to reproduce it here, even with a restore of a backup of their database.
Post #1404751
Posted Wednesday, January 9, 2013 7:15 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Yesterday @ 3:46 PM
Points: 42,462, Visits: 35,525
Unfortunately I would need to see more info to really help with this. It's not a standard or known problem with a well documented solution. Could be a million things.

For now, can you ask that client to run a full stats updates on any tables that those selects affect?



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

Post #1404761
Posted Wednesday, January 9, 2013 7:43 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 2:23 AM
Points: 367, Visits: 674
The client's database has a nightly maintenance job to reindex.

Really, I was just wondering if there was a well known reason why

If A Or B
{Something}

might be massively slow while

If A
{Something}
Else If B
{Something}

is lightning fast. Does SQL try to do something 'clever' with "If A Or B" that it can't do with "If A Else If B"? But if it's "just one of those (performance) things", so be it and thanks for your time!
Post #1404793
Posted Wednesday, January 9, 2013 7:51 AM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Friday, July 25, 2014 3:19 AM
Points: 4,320, Visits: 6,113
julian.fletcher (1/9/2013)
The client's database has a nightly maintenance job to reindex.

Really, I was just wondering if there was a well known reason why

If A Or B
{Something}

might be massively slow while

If A
{Something}
Else If B
{Something}

is lightning fast. Does SQL try to do something 'clever' with "If A Or B" that it can't do with "If A Else If B"? But if it's "just one of those (performance) things", so be it and thanks for your time!


I have a reason why: in the case of the SEPARATE executions, you have a VERY EFFICIENT PLAN that makes a hit (at least one row found) and it executes the "do something" code and then does the GOTO - thus COMPLETELY SKIPPING THE SECOND IF EXISTS CHECK. That second IF EXISTS has a HORRIBLY SLOW query plan that is being executed when you do the combined-check OR attempt in your first sample code. That query is NOT being "SHORT CIRCUITED" to not run in the EXISTS OR EXISTS scenario because the optimizer doesn't work that way. To my knowledge there are very few things that short-circuit in the optimizer/engine (CASE being one of them).


Best,

Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru at GMail
Post #1404797
Posted Wednesday, January 9, 2013 8:04 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Yesterday @ 3:46 PM
Points: 42,462, Visits: 35,525
julian.fletcher (1/9/2013)
The client's database has a nightly maintenance job to reindex.


May not be frequent enough. May not update the stats needed.

Does SQL try to do something 'clever' with "If A Or B" that it can't do with "If A Else If B"? But if it's "just one of those (performance) things", so be it and thanks for your time!


No, other than the fact that B doesn't have to be run in the second case if A is true.
No this is not 'one of those performance things and so be it'. There will be a reason here, it's not obvious from just seeing an abstraction of the code. I asked for the plans and the wait types to try and ID why and tell you why. It's not a plain case of 'anyone who uses OR is an idiot'



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

Post #1404810
Posted Wednesday, January 9, 2013 8:06 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 2:23 AM
Points: 367, Visits: 674
Thanks, that makes perfect sense, but I forgot to mention that neither condition A or B were met when the code was run, which means that both A and B would have been evaluated.

Hence my confusion.
Post #1404811
Posted Wednesday, January 9, 2013 8:16 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 5:18 AM
Points: 5,014, Visits: 10,515
julian.fletcher (1/9/2013)
The client's database has a nightly maintenance job to reindex.

Really, I was just wondering if there was a well known reason why

If A Or B
{Something}

might be massively slow while

If A
{Something}
Else If B
{Something}

is lightning fast. Does SQL try to do something 'clever' with "If A Or B" that it can't do with "If A Else If B"? But if it's "just one of those (performance) things", so be it and thanks for your time!



I depends on how the optimizer decides to implement the OR predicate.
In fact it's not "If A or B" as you say here, but it's "If EXISTS(SomeQuery) OR EXISTS(SomeQuery)" and it makes a whole lot of difference.
As Kevin said, the optimizer has no concept of short-circuiting and has to build a plan that evaluates all the expressions, regardless of whether they might (marginally) benefit from short-circuiting.
Take this simple query as an example:
IF EXISTS (
SELECT 1
FROM sys.objects
WHERE name = 'spt_values'
)
OR EXISTS (
SELECT 1
FROM spt_monitor
WHERE connections > 0
)
BEGIN
PRINT 1
END

The execution plan it produces on my laptop (2008R2SP2) is the following:



As you can see, the "OR" is implemented using a concatenation operator. The COND WITH QUERY can exit (and somehow short-circuit) as soon as the first result comes in from the (concatenation + nested loop), but in your case the optimizer might have implemented the "OR" with a blocking operator.

It would be great if you could post the execution plan and confirm it.


--
Gianluca Sartori

Get your two-cent-answer quickly
spaghettidba.com
@spaghettidba


  Post Attachments 
plan.png (84 views, 20.86 KB)
Post #1404823
Posted Wednesday, January 9, 2013 8:39 AM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Friday, July 25, 2014 3:19 AM
Points: 4,320, Visits: 6,113
julian.fletcher (1/9/2013)
Thanks, that makes perfect sense, but I forgot to mention that neither condition A or B were met when the code was run, which means that both A and B would have been evaluated.

Hence my confusion.


Now we DEFINITELY need the query plans (and I would like statistics IO ON output too) from each scenario. No other way to know what is happening. But it surely seems logical that a different plan is being created between the two query sets.

Hmm, another possible explanation (although unlikely assuming this is a repeatable scenario) is that the first query was simply blocked for a extended period and when you crafted the second and ran it the blocking lock wasn't in play.


Best,

Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru at GMail
Post #1404833
Posted Thursday, January 10, 2013 3:59 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 2:23 AM
Points: 367, Visits: 674
I think that's it! I should have realised that there would be one execution plan for the "If Exists () Or Exists ()" statement rather than two.

If I have the chance, I'll try to get execution plans but, given it's on a client's live database (and, so far, it's not been reproducible here, even with a restore of their database), this is unlikely.
Post #1405327
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse