David Wilson escribió: > explain analyze select datestamp from vals group by datestamp; > QUERY > PLAN > ------------------------------------------------------------------------------------------------------------------------------------ > HashAggregate (cost=1719740.40..1719783.03 rows=4263 width=4) > (actual time=120192.018..120193.930 rows=4252 loops=1) > -> Seq Scan on vals (cost=0.00..1531261.72 rows=75391472 width=4) > (actual time=17.441..66807.429 rows=75391476 loops=1) > Total runtime: 120195.144 ms > Still doing the sequential scan on the table, but at least it's > avoiding the expensive disk merge sort. It still seems as if I ought > to be able to coax it into using an index for this type of query, > though- especially since it's using one on the other table. Is there > perhaps some way to reformulate the index in such a way as to make it > more useful to the planner? Hmm, why do you think an indexscan would be faster? Since there's no sort step involved, a seqscan as input for the HashAggregate is actually better than an indexscan, because there's no need for the index entries at all. If you want to test, try SET enable_seqscan TO 0 and then rerun the explain analyze. My bet is that it will use the index, and it will take longer. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
