Re: Slow query problem

Richard Huxton <dev(at)archonet(dot)com> writes:
>> The goal was to avoid the sorting which should not be needed with that
>> index (I hope). So I still think that it would help in this case.

> Sorry - not being clear. I can see how it _might_ help, but will the planner
> take into account the fact that even though:
> index-cost > seqscan-cost
> that
> (index-cost + no-sorting) < (seqscan-cost + sort-cost)

Yes, it would.

> assuming of course, that the costs turn out that way.

That I'm less sure about. A sort frequently looks cheaper than a full
indexscan, unless the table is pretty well clustered on that index,
or you knock random_page_cost way down.

With no stats at all, CVS tip has these preferences:

regression=# create table fooey (f1 int, f2 int, unique(f1,f2));
NOTICE: CREATE TABLE / UNIQUE will create implicit index "fooey_f1_key" for table "fooey"
CREATE TABLE
regression=# explain select * from fooey group by f1,f2;
QUERY PLAN
---------------------------------------------------------------
HashAggregate (cost=25.00..25.00 rows=1000 width=8)
-> Seq Scan on fooey (cost=0.00..20.00 rows=1000 width=8)
(2 rows)

regression=# set enable_hashagg TO 0;
SET
regression=# explain select * from fooey group by f1,f2;
QUERY PLAN
------------------------------------------------------------------------------------
Group (cost=0.00..57.00 rows=1000 width=8)
-> Index Scan using fooey_f1_key on fooey (cost=0.00..52.00 rows=1000 width=8)
(2 rows)

regression=# set enable_indexscan TO 0;
SET
regression=# explain select * from fooey group by f1,f2;
QUERY PLAN
---------------------------------------------------------------------
Group (cost=69.83..77.33 rows=1000 width=8)
-> Sort (cost=69.83..72.33 rows=1000 width=8)
Sort Key: f1, f2
-> Seq Scan on fooey (cost=0.00..20.00 rows=1000 width=8)
(4 rows)

but remember this is for a relatively small (estimated size of) table.

regards, tom lane