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

Fwd: Re: Endless loop in ExecNestLoop

From: Philipp Reisner <philipp(dot)reisner(at)linbit(dot)com>
To: clifford(at)linbit(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Fwd: Re: Endless loop in ExecNestLoop
Date: 2006-01-31 15:47:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs

----------  Weitergeleitete Nachricht  ----------

Subject: Re: [BUGS] Endless loop in ExecNestLoop
Date: Dienstag, 31. Januar 2006 16:39
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Philipp Reisner <philipp(dot)reisner(at)linbit(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org

Philipp Reisner <philipp(dot)reisner(at)linbit(dot)com> writes:
> Well after more research it turned out that sometimes we have a plan
> that executes in less than 2 seconds, and somethimes we get a plan
> does not terminate within 1h30 of CPU time.

Could you send EXPLAIN ANALYZE output for this (at least for the fast
case)?  Presumably some of the planner's estimates are way off, but
there's no way to know which ones from just EXPLAIN.

>> What reasons are there for the planer to choose a different plan ?

It looks to me like the statistics have changed, because it's showing

different rowcount and width estimates for the same scan:
>                                        ->  Index Scan using
> contractelements_pkey on contractelements cel  (cost=0.00..5574.21 rows=459
> width=22) Filter: (upper((isactiv)::text) = 'Y'::text)
>                                        ->  Seq Scan on contractelements cel
>  (cost=0.00..4253.10 rows=387 width=21) Filter: (upper((isactiv)::text) =
> 'Y'::text)

Perhaps you ran VACUUM or ANALYZE in between, or autovacuum did so for

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?



: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria :

In response to

pgsql-bugs by date

Next:From: Matthias KleinDate: 2006-01-31 15:51:03
Subject: BUG #2227: Internal account lookup error
Previous:From: Patrick RotsaertDate: 2006-01-31 15:47:12
Subject: Re: BUG #2225: Backend crash -- BIG table

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