Re: The old "not using index" question
От | Stephan Szabo |
---|---|
Тема | Re: The old "not using index" question |
Дата | |
Msg-id | 20021202080923.F53151-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: The old "not using index" question ("Jan-Philipp 'Thefly' Reining" <jpr@turtle-entertainment.de>) |
Список | pgsql-general |
On Mon, 2 Dec 2002, Jan-Philipp 'Thefly' Reining wrote: > EXPLAIN > => explain analyze SELECT * > -> FROM ttm_slots s > -> WHERE s.peering = 72 > -> AND s.ranking = 1050 > -> ; > NOTICE: QUERY PLAN: > > Index Scan using ranking_ttm_slots_key on ttm_slots s (cost=0.00..191.06 > rows=8 width=62) (actual time=0.26..0.83 rows=7 loops=1) > Total runtime: 1.02 msec > > EXPLAIN > => explain analyze SELECT * > -> FROM ttm_slots s > -> WHERE s.peering = 72 > -> AND s.ranking < 1050 > -> AND s.ranking > 950 > -> ; > NOTICE: QUERY PLAN: > > Seq Scan on ttm_slots s (cost=0.00..1823.64 rows=7949 width=62) (actual > time=0.08..361.12 rows=9840 loops=1) > Total runtime: 379.47 msec Have you tried running these after a set enable_seqscan=off; The row estimates seem to be reasonably correct (comparing real rows to estimated rows) so I'd guess that it's estimating that it's returning enough of the rows to make the sequence scan faster. How many rows are in ttm_slots?
В списке pgsql-general по дате отправления: