Re: Seeking help with a query that takes too long
От | Manfred Koizar |
---|---|
Тема | Re: Seeking help with a query that takes too long |
Дата | |
Msg-id | p7a5rv0too2u2p745170r3utnoae5ro28j@email.aon.at обсуждение исходный текст |
Ответ на | Re: Seeking help with a query that takes too long ("Nick Fankhauser" <nickf@ontko.com>) |
Ответы |
Re: Seeking help with a query that takes too long
|
Список | pgsql-performance |
On Wed, 12 Nov 2003 13:27:53 -0500, "Nick Fankhauser" <nickf@ontko.com> wrote: > >> You might have to resort to brute force, like "set enable_nestloop=false". > -> Seq Scan on >actor_case_assignment (cost=0.00..209980.49 rows=8669349 width=34) (actual >time=9.13..85504.05 rows=8670467 loops=1) Does actor_case_assignment contain more columns than just the two ids? If yes, do these additional fields account for ca. 70 bytes per tuple? If not, try VACUUM FULL ANALYSE actor_case_assignment; > -> Index Scan using >actor_full_name_uppercase on actor (cost=0.00..6.01 rows=1 width=42) >(actual time=51.67..24900.53 rows=3502 loops=1) This same index scan on actor has been much faster in your previous postings (677ms, 3200ms), probably due to caching effects. 7ms per tuple returned looks like a lot of disk seeks are involved. Is clustering actor on actor_full_name_uppercase an option or would this slow down other queries? Servus Manfred
В списке pgsql-performance по дате отправления: