Skip site navigation (1) Skip section navigation (2)

Re: cost and actual time

From: "Josh Berkus" <josh(at)agliodbs(dot)com>
To: Chantal Ackermann <chantal(dot)ackermann(at)biomax(dot)de>,pgsql-performance(at)postgresql(dot)org
Subject: Re: cost and actual time
Date: 2003-02-13 20:08:22
Message-ID: web-2838434@davinci.ethosmedia.com (view raw or flat)
Thread:
Lists: 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

In response to

Responses

pgsql-performance by date

Next:From: Greg StarkDate: 2003-02-13 20:47:08
Subject: Re: Changing the default configuration (was Re:
Previous:From: Bruce MomjianDate: 2003-02-13 18:49:06
Subject: Re: Changing the default configuration (was Re:

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group