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 |
Subject: | Re: Endless loop in ExecNestLoop |
Date: | 2006-01-31 15:39:58 |
Message-ID: | 4204.1138721998@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
you?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Patrick Rotsaert | 2006-01-31 15:47:12 | Re: BUG #2225: Backend crash -- BIG table |
Previous Message | Tom Lane | 2006-01-31 15:18:06 | Re: BUG #2225: Backend crash -- BIG table |