Re: Slow query problem
От | Tom Lane |
---|---|
Тема | Re: Slow query problem |
Дата | |
Msg-id | 23792.1073660829@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Slow query problem (Richard Huxton <dev@archonet.com>) |
Список | pgsql-performance |
Richard Huxton <dev@archonet.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
В списке pgsql-performance по дате отправления: