SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


What's the best way to count?


What's the best way to count?

Author
Message
UMG Developer
UMG Developer
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2686 Visits: 2204
I answered it correctly because I knew what the author was talking about, but for myself I will stick with COUNT(*). (It runs in under 2 seconds on our 70 GB table, so speed isn't that big of an issue.)

Also, most code completion tools won't help you with the schema and table name when writing the alternate count queries.
UMG Developer
UMG Developer
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2686 Visits: 2204
Oleg Netchaev (10/19/2010)
Very true indeed. I did have quite few unfortunate years in my career when I had to work with Oracle databases. I remember it used to really frustrate me that the select count(*) from the_table; in Oracle takes forever longer than the similar query against similar table in SQL Server. Of course there was a decent workaround to NEVER use count(*), but opt for a much better performing count('X') instead, but still it was frustrating.


I don't know that that is true anymore, at least with Oracle 10g. Count(*) is still slow compared to SQL Server, but I find that Count('X') is even slower. (36 secs vs. 80 secs in my test.)
Oleg Netchaev
Oleg Netchaev
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1779 Visits: 1814
UMG Developer (10/19/2010)
I don't know that that is true anymore, at least with Oracle 10g. Count(*) is still slow compared to SQL Server, but I find that Count('X') is even slower. (36 secs vs. 80 secs in my test.)

Fortunately for me, I don't know anything about Oracle past version 8i and 9. Perhaps they figured out how to speed up their count(*) by now (it is 21st century after all). The bottom line is that the execution time of Oracle's count(*) is still inferior when compared with SQL Server 2000 or better.

Oleg
sharath.chalamgari
sharath.chalamgari
UDP Broadcaster
UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)

Group: General Forum Members
Points: 1482 Visits: 798
The Question and the discussion is awesome.
TomThomson
TomThomson
SSChampion
SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)SSChampion (14K reputation)

Group: General Forum Members
Points: 14308 Visits: 12197
mtillman-921105 (10/19/2010)
kevin.l.williams (10/19/2010)
If I saw any production code like 2, 3 or 4, the developer would get an ear full. I will stick with count(*) thank you very much.


Maybe you're right for most everyday applications. I just tested SELECT COUNT(*) on a table with 5,900,000 rows and it was almost immediate. I think I'll stick with that too.

I think that I was being too hard on MS earlier since COUNT(*) is accurate, even if it can be slow in some circumstances.

COUNT(*) is only guaranteed accurate if your isolation level is REPEATABLE READ, SERIALIZABLE, or SNAPSHOT (or of course if you use HOLDLOCK).

Tom

Alexander Kuznetsov
Alexander Kuznetsov
SSC-Addicted
SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)

Group: General Forum Members
Points: 405 Visits: 824
del
mtillman-921105
mtillman-921105
SSC Eights!
SSC Eights! (826 reputation)SSC Eights! (826 reputation)SSC Eights! (826 reputation)SSC Eights! (826 reputation)SSC Eights! (826 reputation)SSC Eights! (826 reputation)SSC Eights! (826 reputation)SSC Eights! (826 reputation)

Group: General Forum Members
Points: 826 Visits: 3852
Tom.Thomson (10/21/2010)
mtillman-921105 (10/19/2010)
kevin.l.williams (10/19/2010)
If I saw any production code like 2, 3 or 4, the developer would get an ear full. I will stick with count(*) thank you very much.


Maybe you're right for most everyday applications. I just tested SELECT COUNT(*) on a table with 5,900,000 rows and it was almost immediate. I think I'll stick with that too.

I think that I was being too hard on MS earlier since COUNT(*) is accurate, even if it can be slow in some circumstances.

COUNT(*) is only guaranteed accurate if your isolation level is REPEATABLE READ, SERIALIZABLE, or SNAPSHOT (or of course if you use HOLDLOCK).


For real? I'll have to look into that Tom. By the way, NULLs do count in a COUNT(*) - I did notice that. :-D

______________________________________________________________________
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
Alexander Kuznetsov
Alexander Kuznetsov
SSC-Addicted
SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)SSC-Addicted (405 reputation)

Group: General Forum Members
Points: 405 Visits: 824
mtillman-921105 (10/21/2010)
Tom.Thomson (10/21/2010)
mtillman-921105 (10/19/2010)
kevin.l.williams (10/19/2010)
If I saw any production code like 2, 3 or 4, the developer would get an ear full. I will stick with count(*) thank you very much.


Maybe you're right for most everyday applications. I just tested SELECT COUNT(*) on a table with 5,900,000 rows and it was almost immediate. I think I'll stick with that too.

I think that I was being too hard on MS earlier since COUNT(*) is accurate, even if it can be slow in some circumstances.

COUNT(*) is only guaranteed accurate if your isolation level is REPEATABLE READ, SERIALIZABLE, or SNAPSHOT (or of course if you use HOLDLOCK).


For real? I'll have to look into that Tom. By the way, NULLs do count in a COUNT(*) - I did notice that. :-D


I cannot completely agree.
In fact, COUNT(*) under REPEATABLE READ may return wrong results. I wrote a repro script here:[url=http://sqlblog.com/blogs/alexander_kuznetsov/archive/2010/10/21/myth-busting-count-under-repeatable-read-may-return-wrong-results.aspx][/url]
Mark D Powell
Mark D Powell
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1844 Visits: 463
I think the answer is wrong on 2005. Look at the following:

select
sum(row_count)
from
sys.dm_db_partition_stats
where
object_id = object_id('dibs_tmb_saalist') and
(index_id = 0 or index_id = 1)

select count(*) from dibs_tmb_saalist
go

Produced:
(No column name)
310825

(No column name)
311992

That is a pretty significant error in my book. Query 1 is the only reliable method posted.

HTH -- Mark D Powell --
Note - above is corrected to include index_id line which reduced the error but did not eliminate it.
UMG Developer
UMG Developer
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2686 Visits: 2204
You didn't include the restriction on the index_id in your query on the DMV, so that might be the issue.

Try this and see what you get:


select
sum(row_count)
from
sys.dm_db_partition_stats
where
object_id = object_id('dibs_tmb_saalist')
and index_id in (0,1)


Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search