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 по дате отправления:

Предыдущее
От: Neil Conway
Дата:
Сообщение: Re: performance optimzations
Следующее
От: Suchandra Thapa
Дата:
Сообщение: Re: performance optimzations