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 «««23456»»

What's the best way to count? Expand / Collapse
Author
Message
Posted Tuesday, October 19, 2010 6:01 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, June 16, 2014 9:38 AM
Points: 2,163, Visits: 2,189
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.
Post #1007400
Posted Tuesday, October 19, 2010 6:08 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, June 16, 2014 9:38 AM
Points: 2,163, Visits: 2,189
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.)
Post #1007401
Posted Tuesday, October 19, 2010 8:15 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, July 10, 2014 12:49 PM
Points: 1,676, Visits: 1,754
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
Post #1007420
Posted Tuesday, October 19, 2010 11:50 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, July 22, 2014 2:49 AM
Points: 1,179, Visits: 783
The Question and the discussion is awesome.
Post #1007470
Posted Thursday, October 21, 2010 8:19 AM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Yesterday @ 5:31 PM
Points: 8,577, Visits: 9,090
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
Post #1008519
Posted Thursday, October 21, 2010 8:55 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Saturday, May 24, 2014 7:58 PM
Points: 219, Visits: 824
del
Post #1008558
Posted Thursday, October 21, 2010 8:59 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Monday, July 14, 2014 10:08 AM
Points: 754, Visits: 3,816
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.


______________________________________________________________________
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
Post #1008562
Posted Thursday, October 21, 2010 10:51 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Saturday, May 24, 2014 7:58 PM
Points: 219, 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.


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]
Post #1008668
Posted Friday, October 22, 2010 12:15 PM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, June 17, 2014 10:33 AM
Points: 1,361, Visits: 380
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.
Post #1009417
Posted Friday, October 22, 2010 12:19 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, June 16, 2014 9:38 AM
Points: 2,163, Visits: 2,189
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)

Post #1009421
« Prev Topic | Next Topic »

Add to briefcase «««23456»»

Permissions Expand / Collapse