This question already has answers here:
CASE vs. DECODE
(7 answers)
Closed 6 years ago.
For some simple logical tests the same functionality can be achieved with CASE WHEN and DECODE syntax. What approach is better here (argumentation/measurement needed)?
SUM(CASE WHEN xyz=100 THEN 1 ELSE 0 END)
or
SUM(DECODE(xyz,100,1,0))
Recently I stumbled upon this: https://community.oracle.com/thread/1112467?tstart=0
"The performance difference is so slight that it makes very little sense in using that as primary criteria for whether to use CASE or DECODE. So unless you're calling this statement from a very tight loop doing millions of iterations, the decision should rather be which one, CASE or DECODE, best suits the need."
Related
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 1 year ago.
Improve this question
In the SQL toy example below, SUM() is called twice. Is there any trick to do the computation of a function just once? The reason behind this is that calling twice may be less efficient.
CREATE TABLE #Tmp(Id int);
INSERT INTO #Tmp VALUES (1), (2), (-10);
SELECT IIF(SUM(Id) < 0, 0, SUM(Id)) FROM #Tmp;
In Python, we have so-called Assignment Expressions:
if (list_length := len(some_list)) < 0:
return 0
else:
return list_length
In C#, we have coalesce operator: ??
var x = callFunctionThatCouldReturnNull() ?? valueIfNull;
...at least help us in case of checking null.
Do we have something similar in SQL? One can workaround by assigning to a variable, but then more code to write...
-- Updated --
I need something similar in SQL because of:
Syntatic sugar: repeating code is boring.
Potential performance issue: as said in comments, SQL Compiler may be intelligent enough to recognize the function SUM() is called twice. But what if we have a very complex/long query in IIF() (instead of just SUM()), is it always guaranteed that SQL Compiler also detects that those code snippets are the same, so it saves the result from the 1st call and re-use later?
There are some misconceptions that you have about SQL queries.
In general, the expensive part of the query is reading the data, not doing the sum. This is especially true on trivially small amounts of data.
Second, SQL queries describe the result set. SQL is a declarative language, not a procedural language. The optimizer is free to see that there are two SUM()s that can be calculated only once. I'm not so sure that SQL Server does this optimization.
There are some cases where calling functions can be expensive (I don't think SUM() on integers is one of those cases). If this is a concern, you can use a subquery:
SELECT (CASE WHEN sum_id < 0 THEN 0 ELSE sum_id END)
FROM (SELECT SUM(Id) as sum_id
FROM #Tmp t
) t;
Also note that I replaced the IIF() with the standard SQL CASE expression.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
Using Linq and EntityFramework we recently noticed, while testing our queries performances, that the use of Equal(=) operator to compare two integers takes around 800ms more than using a combination of GreaterThan(>) and LessThan(<) operators.
So basically, replacing itemID == paramID (Both being integers) by !(itemID > param ID || itemID < paramID) in our linq query makes the query faster by about 800ms consistently.
Anyone with a deep knowledge of SQL could explain this result to me?
If this was always faster SQL Server would do the rewrite for you. It does not so you can conclude that it is not always faster to do this. In fact it is a bad idea to do this rewrite in 99.999% of the cases.
The information given in the question (almost none) does not allow for further analysis.
Often people ask "why did this random change make my query faster". The answer is always: You accidentally triggered a better query plan. There is no system to it. Query plans can be unstable.
Psychic guess: The complex predicate forces a table scan (or makes it appear better) than using an index. That can sometimes be a good thing.
The first step would be to examine the generated sql. My guess is itemID is nullable and EntityFramework's default behaviour with nullable properties isn't the greatest. It will translate your query into something like: prop = value OR prop is null
If that is the case and you are using EF6, you can overide that behaviour by:
context.UseDatabaseNullSemantics = true;
Msdn
This question already has answers here:
How to get around the Scala case class limit of 22 fields?
(5 answers)
Closed 8 years ago.
This is a challenge specific to SPARK-SQL and I'm unable to apply two highlighted answers
I'm writing complex data processing logic in SPARK-SQL.
Here is the process I follow ,
Define case class for a table with all attributes.
Register that as table.
Use SQLContext to query the same.
I'm encountering an issue as Scala allows only 22 parameters whereas my table has 50 columns. Only approach I could think of is to break dataset in such a way that it has 22 parameters and combine them later at the end. It does not look like a clean approach. Is there any better approach to this issue ?
Switch to Scala 2.11 and the case class field limit is gone. Release notes. Issue.
Recently, I have been tasked with some major refactoring of a project coded prior to my arrival. Part of this refactoring involves going through some stored procedures and cleaning them up and make some general changes to their behavior. I recently came across the following statement:
IF
CASE
WHEN EXISTS
(
SELECT *
FROM users
WHERE Username = 'admin'
) THEN 1
ELSE 0
END <> 0
//Do something here
After starring at this piece of code for a while and doing a little research, I eventually came to the conclusion that the logic of the code above can be accomplished by writing:
IF EXISTS (
SELECT *
FROM users
WHERE Username = 'admin'
)
//Do something here
So my question is this: what would be the advantage to using the case statement? It seems bulkier than the if statement, and less readable too. Is there a compatibility advantage that I'm not seeing? Or am I wrong in saying that these two queries are equivalent, and are there cases where they will behave differently?
As a side note, I'm not terribly concerned in the performance advantages of using CASE statements over if statements. But for those who found themselves on this page looking for just that, there's a good answer here about it.
Maintainability if one can assume tha more than one condition will be needed over a relatively short timeframe.
Pretty much the only reason I can come up with ;)
There's a lot of misinformation in some of the comments here. Fortunately you did change it to an "IF" statement, but for future viewers of this page:
See #damien-the-unbeliever's first comment on question here: MS SQL - CASE vs IF performance
See forum topic (just the top few posts) here: http://www.sqlservercentral.com/Forums/Topic1206250-392-1.aspx
Basically, the IF/ELSE statements and CASE expressions are two fundamentally different parts of the language, and are not used interchangeably. IF/ELSE is for control-flow within a batch or stored-procedure; CASE is for "choosing" a data-value within a SELECT or similar operation.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Speed difference between If-Else and Ternary operator in C…?
This is a very simple question, does the ternary operator increase the speed of execution in comparison to if else statement?
No. Most languages parse it to a very similar syntax tree. Any jit/optimizer is going to collapse it into 'basic blocks' of simple instructions without jumps; and from that point on it will optimize the same.
There could, of course, be some really bad systems out there for which this is not true; but gcc/msvc/c# will all deal with it equally well.
It's abundance can usually be associated with the fact that it is an expression instead of just a logic statement. This makes it all to easy to do things like (note: really ugly example ahead):
size_t n = strlen( pszVar == NULL ? "" : pszVar );