InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSun, 26 May 2013 03:09:38 GMT20http://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxI 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.Thu, 10 Jan 2013 03:59:31 GMTjulian.fletcherhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspx[quote][b]julian.fletcher (1/9/2013)[/b][hr]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.[/quote]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.Wed, 09 Jan 2013 08:39:34 GMTTheSQLGuruhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspx[quote][b]julian.fletcher (1/9/2013)[/b][hr]The client's database has a nightly maintenance job to reindex.Really, I was just wondering if there was a well known reason why[code="sql"]If A Or B {Something}[/code]might be massively slow while[code="sql"]If A {Something}Else If B {Something}[/code]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![/quote]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:[code]IF EXISTS ( SELECT 1 FROM sys.objects WHERE name = 'spt_values')OR EXISTS ( SELECT 1 FROM spt_monitor WHERE connections > 0)BEGIN PRINT 1END [/code]The execution plan it produces on my laptop (2008R2SP2) is the following:[img]http://www.sqlservercentral.com/Forums/Attachment12950.aspx[/img]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.Wed, 09 Jan 2013 08:16:48 GMTspaghettidbahttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxThanks, 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.Wed, 09 Jan 2013 08:06:10 GMTjulian.fletcherhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspx[quote][b]julian.fletcher (1/9/2013)[/b][hr]The client's database has a nightly maintenance job to reindex.[/quote]May not be frequent enough. May not update the stats needed.[quote]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![/quote]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'Wed, 09 Jan 2013 08:04:35 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspx[quote][b]julian.fletcher (1/9/2013)[/b][hr]The client's database has a nightly maintenance job to reindex.Really, I was just wondering if there was a well known reason why[code="sql"]If A Or B {Something}[/code]might be massively slow while[code="sql"]If A {Something}Else If B {Something}[/code]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![/quote]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).Wed, 09 Jan 2013 07:51:34 GMTTheSQLGuruhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxThe client's database has a nightly maintenance job to reindex.Really, I was just wondering if there was a well known reason why[code="sql"]If A Or B {Something}[/code]might be massively slow while[code="sql"]If A {Something}Else If B {Something}[/code]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!Wed, 09 Jan 2013 07:43:02 GMTjulian.fletcherhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxUnfortunately 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?Wed, 09 Jan 2013 07:15:44 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxIt 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.Wed, 09 Jan 2013 06:47:48 GMTjulian.fletcherhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxIn case you missed this...[quote][b]GilaMonster (1/9/2013)[/b][hr]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.[/quote]Wed, 09 Jan 2013 06:42:15 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxApologies. That should be comparing[code="sql"]If A Or B {Do something}[/code]with[code="sql"]If ABegin {Do something} Goto EndItEndIf B {Do something}EndIt:[/code]Wed, 09 Jan 2013 06:40:51 GMTjulian.fletcherhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxJust 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, [code="sql"]IF A OR BBEGIN {do something}END[/code]is not the same as [code="sql"]IF A BEGIN {do something} ENDIF BBEGIN {do something} END[/code]Wed, 09 Jan 2013 05:47:36 GMThemanth.damecharlahttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxThanks 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[code="sql"]If A Or B {Do something}[/code]with[code="sql"]If A {Do something}If B {Do something}[/code]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.Wed, 09 Jan 2013 03:10:11 GMTjulian.fletcherhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxthanks gailWed, 09 Jan 2013 03:06:25 GMTBhuvneshhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspx[quote][b]Bhuvnesh (1/9/2013)[/b][hr][quote][b]julian.fletcher (1/9/2013)[/b][hr]Really? Do you have any links to further details? That would be very helpful.[/quote] sse this link [url]http://sqlserverplanet.com/optimization/using-union-instead-of-or[/url][/quote]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:[quote]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.[/quote]The one with the Union:[quote]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.[/quote]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.Wed, 09 Jan 2013 03:03:51 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspx[quote][b]julian.fletcher (1/9/2013)[/b][hr]Really? Do you have any links to further details? That would be very helpful.[/quote] sse this link [url]http://sqlserverplanet.com/optimization/using-union-instead-of-or[/url]Wed, 09 Jan 2013 03:00:49 GMTBhuvneshhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxThere 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.Wed, 09 Jan 2013 02:51:53 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxReally? Do you have any links to further details? That would be very helpful.Wed, 09 Jan 2013 01:34:35 GMTjulian.fletcherhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxits happening because of OR usage in first query , yes it is well know performance glitch.Wed, 09 Jan 2013 01:21:00 GMTBhuvneshhttp://www.sqlservercentral.com/Forums/Topic1404058-360-1.aspxDoes anybody know why the following[code="sql"]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_EndEnd[/code]might take 10 minutes to run while this version[code="sql"]If Exists (Select * From Inserted I Join dbo.T_PaymentItemGroup PIG On PIG.PaymentItemGroupID = I.PaymentItemGroupID Join ...)Begin {Do something} Goto TR_EndEndIf Exists (Select * From Inserted I Join dbo.T_PaymentItem PAY On PAY.PaymentItemID = I.PaymentItemID Join ...)Begin {Do something} Goto TR_EndEnd[/code]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 ...)"?Tue, 08 Jan 2013 02:08:58 GMTjulian.fletcher