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 wid开发者_如何学JAVAth=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.
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.
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.
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).
精彩评论