Reputation: 110267
An index can be used to do something like this:
SELECT name FROM bigtable GROUP BY name
That is, it can traverse the btree or whatever index structure there is to get the values. However, does an index help at all with something like this?
SELECT name, count(1) FROM bigtable GROUP BY name
Note that for purposes of this question there won't be a filter or sort applied.
My thought is it wouldn't because a table-scan would be needed (regardless of whether there's an index in place) to "sum up" all the values. Is this correct, or am I missing something here? Are indexes ever helpful for aggregated calculations? How or how not?
Other than pre-storing the values, are there any ways to speed up the calculation of these values, or it's really just a matter of disk-speed here.
Upvotes: 0
Views: 923
Reputation: 262554
My thought is it wouldn't because a table-scan would be needed (regardless of whether there's an index in place) to "sum up" all the values.
No, you can also just scan the index instead. It contains (in your example) an entry for each row and its name
column value.
And unlike the table, the index will already be grouped/sorted by name
, so that no additional sorting step is required. If you tried to do this with a full-table-scan, you would need a lot of memory or temporary space to run up the counters for each name.
That second part is what makes the big difference here (not so much that scanning the whole index is faster than scanning the whole table, which is also true of course, because it is smaller and maybe already cached).
You should be able to easily verify this by looking at the execution plan.
Note that for purposes of this question there won't be a filter or sort applied.
If you did refer to other columns in the query, the index is no longer a "covering index" and could no longer be used (by itself) to satisfy the query.
Upvotes: 2