From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | Dennis Björklund <db(at)zigo(dot)dhs(dot)org>, Bradley Tate <btate(at)objectmastery(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Slow query problem |
Date: | 2004-01-09 15:07:09 |
Message-ID: | 23792.1073660829@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2004-01-09 15:38:01 | Re: Slow query problem |
Previous Message | Bradley Tate | 2004-01-09 14:53:41 | Re: Slow query problem |