Re: Seeking help with a query that takes too long

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

In response to

Responses

Browse pgsql-performance by date

  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