From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | <nickf(at)ontko(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Pgsql-Performance(at)Postgresql(dot) Org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Seeking help with a query that takes too long |
Date: | 2003-11-12 22:25:54 |
Message-ID: | p7a5rv0too2u2p745170r3utnoae5ro28j@email.aon.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, 12 Nov 2003 13:27:53 -0500, "Nick Fankhauser"
<nickf(at)ontko(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2003-11-12 22:29:30 | Re: performance optimzations |
Previous Message | Rajesh Kumar Mallah | 2003-11-12 21:25:20 | Re: Suggestions for benchmarking 7.4RC2 against 7.3 |