Question

I have a table t with a column c, which is an int and has a btree index on it.

Why does the following query not utilize this index?

explain select c from t group by c;

The result I get is:

HashAggregate  (cost=1005817.55..1005817.71 rows=16 width=4)
  ->  Seq Scan on t  (cost=0.00..946059.84 rows=23903084 width=4)

My understanding of indexes is limited, but I thought such queries were the purpose of indexes.

Was it helpful?

Solution

The query certainly can use an index. The reason that it doesn't in your particular case depends on the particular size and distribution of the data. You can use SET enable_seqscan TO off to investigate.

OTHER TIPS

This query can be performed using an optimization called a loose index scan. However PostgreSQL doesn't yet implement this optimization, so it uses a table scan instead.

Of the major databases, as far as I know only MySQL has implemented loose index scan (perhaps Oracle too?). PostgreSQL hasn't implemented this feature.

Because it requires scanning the entire table, so doing that via the index is of no benefit. ("Covering indices" aren't useful as a performance technique in PostgreSQL due to its MVCC implementation).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top