On Wed, 12 Nov 2003 13:27:53 -0500, "Nick Fankhauser"
>> 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?


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to