Recently, I’ve encountered this sort of query all over the place at a customer site:
DECLARE
v_var NUMBER(10);
BEGIN
SELECT COUNT(*)
INTO v_var
FROM table1
JOIN table2 ON table1.t1_id = table2.t1_id
JOIN table3 ON table2.t2_id = table3.t2_id
...
WHERE some_predicate;
IF (v_var = 0) THEN
do_something
ELSE
do_something_else
END IF;
END;
Unfortunately, COUNT(*) is often the first solution that comes to mind when we want to check our relations for some predicate. But COUNT() is expensive, especially if all we’re doing is checking our relations for existence. Does the word ring a bell? Yes, we should use the EXISTS predicate, because if we don’t care about the exact number of records that return true for a given predicate, we shouldn’t go through the complete data set to actually count the exact number. The above PL/SQL block can be rewritten trivially to this one:
DECLARE
v_var NUMBER(10);
BEGIN
SELECT CASE WHEN EXISTS (
SELECT 1
FROM table1
JOIN table2 ON table1.t1_id = table2.t1_id
JOIN table3 ON table2.t2_id = table3.t2_id
...
WHERE some_predicate
) THEN 1 ELSE 0 END
INTO v_var
FROM dual;
IF (v_var = 0) THEN
do_something
ELSE
do_something_else
END IF;
END;
Let’s measure!
Query 1 yields this execution plan:
You can ignore the TABLE ACCESS FULL operations, the actual query was executed on a trivial database with no indexes.
What’s essential, however, are the much improved E-Rows values (E = Estimated) and even more importantly the optimal A-Rows values (A = Actual). As you can see, the EXISTS predicate could be aborted early, as soon as the first record that matches the predicate is encountered – in this case immediately.
See this post about more details of how to collect Oracle Execution plans
The same is true for SQL Server
Bruce Gordon from Webucator’s SQL Training team had picked up the topic to create a short video demo where he showed that the same kind of difference can be observed in SQL Server as well:
Conclusion
Whenever you encounter a COUNT(*) operation, you should ask yourself if it is really needed. Do you really need to know the exact number of records that match a predicate? Or are you already happy knowing that any record matches the predicate?
Answer: It’s probably the latter.
2 thoughts on “SQL Tip of the Day: Be Wary of SELECT COUNT(*)”
Please note, the example SQL query at the beginning of this post does NOT test for existence; it tests that there is one AND ONLY ONE record that meets the query criteria. If there are 2 matching records then the original example would call “do_something_else” whereas your PL/SQL code would call “do_something”.
Had the “IF” statement in the original example started with:
IF (v_var > 0) THEN
… then your premise would have been correct.
Love your articles. I’ve a learned a lot reading them, and you’re one of the few authors worth reading on the “java.dzone.com” site.
Please note, the example SQL query at the beginning of this post does NOT test for existence; it tests that there is one AND ONLY ONE record that meets the query criteria. If there are 2 matching records then the original example would call “do_something_else” whereas your PL/SQL code would call “do_something”.
Had the “IF” statement in the original example started with:
IF (v_var > 0) THEN
… then your premise would have been correct.
Love your articles. I’ve a learned a lot reading them, and you’re one of the few authors worth reading on the “java.dzone.com” site.
You’re right of course. That was a “copy paste” error on my part. The original code checked for
v_var = 0. Will fix that in the article.Thanks for your nice words. I’ll certainly continue blogging about the Java / SQL experience made here at Data Geekery.