Re: cost and actual time - Mailing list pgsql-performance

From Josh Berkus
Subject Re: cost and actual time
Date
Msg-id web-2838434@davinci.ethosmedia.com
Whole thread Raw
In response to cost and actual time  (Chantal Ackermann <chantal.ackermann@biomax.de>)
Responses Re: cost and actual time
List pgsql-performance
Chantal,

> Sort Key: disease.disease_name, disease_occurrences.sentence_id
> ->  Nested Loop  (cost=0.00..6922.38 rows=98 width=64) (actual
> time=61.49..275047.46 rows=18910 loops=1)
>   ->  Nested Loop  (cost=0.00..6333.23 rows=98 width=28) (actual
> time=61.42..274313.87 rows=18910 loops=1)
>     ->  Nested Loop  (cost=0.00..5894.04 rows=64 width=16) (actual
> time=32.00..120617.26 rows=46849 loops=1)
>
> I tried to tweak the conf settings, but I think I already reached
> quite a good value concerning shared buffers and sort mem. the
> database is vacuum full analyzed. indexes seem fine.

You *sure* that you've vacuum analyzed recently?   The planner above is
choosing a bad plan because its row estimates are way off ... if the
subquery was actually returning 98 rows, the plan above would make
sense ... but with 18,000 rows being returned, a Nested Loop is
suicidal.

Perhaps you could post the full text of the query?  If some of your
criteria are coming from volatile functions, then that could explain
why the planner is so far off ...

-Josh Berkus

pgsql-performance by date:

Previous
From: Chantal Ackermann
Date:
Subject: cost and actual time
Next
From: Nick Pavlica
Date:
Subject: Re: JBoss CMP Performance Problems with PostgreSQL 7.2.3