Comments on: A common problem when optimizing COUNT()

By: victori

victori — Sat, 29 Nov 2008 19:08:41 +0000

@2. Pat

count(*) can be fast on postgresql by counting tuples instead of actually rows. Yes the number returned isn’t accurate but works great for pagination. When was the last time a user went to page 10,000? only the first few pages are relevant.

select reltuples from pg_class where relname=”;

Replace …

Just one of the few tricks I am using to getting the most out of our database.

By: Rob Wultsch

Rob Wultsch — Thu, 25 Sep 2008 19:40:23 +0000

Heck knowing where a sql query is coming from is half the battle. With the popularity of people doing stuff like:
SELECT $fields
FROM $table $join
$where
$order_by

figuring out context is a real pain in the backside. grep is much less useful with such queries. I wish people would add magic constants like __FILE__ and __LINE__ if they are going to dynamically build the queries…

By: Baron Schwartz

Baron Schwartz — Thu, 25 Sep 2008 14:27:37 +0000

Yes! Comments are great for that. And they can absolutely clarify whether it’s a mistake or intentional. But most of the customers I work with don’t have comments in their SQL.

By: amit

amit — Thu, 25 Sep 2008 14:25:32 +0000

he real question is what did the user intend when writing the query?

comments can be effectively used for that, no?

By: Kailash Badu

Kailash Badu — Tue, 23 Sep 2008 05:59:20 +0000

If COUNT(col1) is not better (in terms of performance) than COUNT(*), I bet itâ€™s not worse either. I also donâ€™t see why COUNT(Col1) is less readable than COUNT(*) when I can easily make out that the developer intends to find the number of rows because col1 is PK. Ok, I have no grudges against COUNT(*). Itâ€™s fine in itself but there is no point in preferring it over COUNT(PK). Even so more in making the massive, system-wide alteration from COUNT(PK) to COUNT(*).

The argument that COUNT(*) is better because itâ€™s immune to changes in table schema doesnâ€™t hold water because if a column name can change, so can a table name. Thus invalidating SELECT COUNT(*) FROM table_name;

By: Eric

Eric — Mon, 22 Sep 2008 23:00:02 +0000

I just found a case of #3 in my code which works as intended, but it was easily rewritten to use count(*). The count(*) version seems to be slightly faster, particularly since the application didn’t care that the zero rows disappeared and was happy enough to not loop over them.

By: Baron Schwartz

Baron Schwartz — Mon, 22 Sep 2008 20:50:21 +0000

Kalaish, the real question is not what is faster. The real question is what did the user intend when writing the query?

To address the off-topic The hope that COUNT(col1) is faster than COUNT(*) is false indeed. Take a look at this:

create table test(
pk char(100) not null,
col1 tinyint not null,
primary key(pk),
key(col1)
) engine = innodb;

Now what do you think MySQL will do with various types of COUNT() queries? Try putting a few rows into the table, then using EXPLAIN with COUNT(*), COUNT(pk) and COUNT(col1). You might be surprised. Convert to MyISAM and try again. Make col1 nullable and try again.

Now imagine the table has a primary key on (col1, col2, … colN). Is COUNT(col1) a good idea? Did the user mean COUNT(DISTINCT col1) or was it someone trying to outsmart the optimizer? Are you still convinced that it’s just as good if not better? Assuming the user wanted to count rows and not values, in the best case it may perform as well as COUNT(*) but never better. What happens when you alter the table’s schema?

The optimizer needs choices, and the consultant who is trying to find out why the choices are forbidden needs information. So the real question still remains, what does the SQL mean? To return to your statement “just as good as COUNT(*), if not better,” what metric of goodness are you using? In performance it can never be better; in optimizability/understandability/maintainability, COUNT(*) always wins when you’re trying to count rows.

The person who commented about LEFT OUTER JOIN is right on the money, that is the most common use I’ve seen for actually counting values instead of rows.

By: Kailash Badu

Kailash Badu — Mon, 22 Sep 2008 20:29:09 +0000

Ok. Why would anyone want to use â€˜SELECT COUNT(col1)â€™ instead of â€˜SELECT COUNT (*)â€™ for finding the number of rows? Probably because the person believes that performing count on a single column is faster than performing it on the entire column set (the spooky star sign has horrible reputation for being slow for normal SELECT queries although it might or might not apply in this particular case). Now, if I do use â€˜SELECT COUNT (col1) for finding number of row in the (possibly false) hope that itâ€™s faster than COUNT(*), I would at least make sure that col1 is a primary key. No NULL values for col1 (PK) means COUNT(col1) would work just as good as COUNT(*), if not better.

The real question should be: is COUNT(col1) faster than COUNT(*

By: Kailash Badu

Kailash Badu — Mon, 22 Sep 2008 20:26:29 +0000

The real question should be: is COUNT(col1) faster than COUNT(*)?

By: idont

idont — Sun, 21 Sep 2008 20:45:30 +0000

What I usually do:

SELECT COUNT(1) FROM mylargetable WHERE ….

I do not know if it is a good idea but that way there is no doubt about the result.