Pergunta

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.

Foi útil?

Solução

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.

Outras dicas

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).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top